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PREFACE 


Objective 

Earth Satellite Corporation, working under NASA Goddard Space 
Flight Center Contract No. NASS- 22894, has designed a geocoded data 
management system applicable for hydrological analysis. The central 
features accommodated by the system design include: 

1. Ability to process a variety of data types related to hydro- 
logical parameters; 

2. Ability to store and retrieve data within a common framework 
for all data types; 

3. Ability to analyze spatial and temporal relationships between 
hydrologically related parameters through video displays and 
overlays; 

4. Ability to drive existing main- frame hydrologic models from 
outputs of the system. 

The emphasis throughout the contract was to demonstrate the utility 
of the Atmospheric and Oceanographic Information Processing System 
(AOIPS) for hydrological applications. Within that context, the geo- 
coded hydrology data management system was designed to take advantage of 
the interactive capability of AOIPS hardware. Portions of the Water 
Resource Data Management System which best demonstrate the interactive 
nature of the hydrology data management system were implemented on the 
AOIPS. A hydrological case study was prepared using all data supplied 
by GSFC for the Bear River watershed located in northwest Utah, south- 
east Idaho, and western Wyoming. 


Scope of Work 


Five distinct activities were performed under this contract: 

1. System definition - Hydrology Applications Scenario was de- 
fined to demonstrate the utility of AOIPS to hydrologists 
using the Bear River watershed as a case study area (approxi- 
mately S% of total effort). 

2. Applications Software Implementation - Approximately 15 
applications software modules were converted for use on AOIPS 
hardware (approximately 40% of total effort). 

3. Data Base Design - A geocoded Water Resources Data Management 
System was designed specifically for implementation on AOIPS 
hardware (approximately 10% of total effort). 

4. Water Resources Data Management System Implementation - A 
portion of the geocoded hydrology application data management 
system was implemented in order to demonstrate the hydrology 
applications scenario (approximately 35% of total effort). 

5. System Documentation (approximately 10% of total effort) - 
Software and system documentation was prepared for: 

a. Hydrology scenario 

fa. Implemented software 

c. Data faase file structure 

d. Geocoded Hydrology Data Management System 

e. Implementation User Guide 


Conclusions 

Previous experience by EarthSat personnel in a variety of applica- 
tion areas has demonstrated the utility of storing application specific 
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data in a geocoded reference system. Work performed under this contract 
has shown the increased advantages of directly tying the geocoded data 
base to an interactive display capability such as that available on 
AOIPS. 

f 

In specific applications of hydrology it should be pointed out that 
the existing hydrology models consider as their "smallest unit of informa 
tion" the watershed basin or sub-basin area. Sub-basin areas may in 
fact cover a large geographic area displaying a variety of terrain, 
vegetation covered patterns, soil types, etc. The natural resolution of 
various remotely sensed data is frequently much smaller than the sub- 
basin level. It is therefore possible to study a watershed area at a 
level much smaller than that currently used by the principal hydrologi- 
cal model. This capability to study a basin or a watershed on a variety 
of spatial levels promises to be a great aid to the application scien- 
tists. 

Summary of Recommendations 

As a result of the work performed under contract NAS5-22894 Earth 
Satellite Corporation recommends; 

1. The implementation of the geocoded Water Resources Applications 
Data Management System be completed with emphasis directed 
towards the river forecast problem. 

2. Potential hydrology application users be strongly encouraged 
to use the existing portions of the system to gain hands-on 
experience with their own hydrology problems. 

Additionally, Earth Satellite scientists believe that v^hile the 
specific details of this system design are currently directed toward the 
hydrology applications area the general design concept used here is 
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applicable, and in fact directly transferable, to many other application 
areas. The geocoded data base is developed for the hydrology applica- 
tions which are structurally similar to the agroraeterological data files 
used by the AGHET yield modeling systems developed at EarthSat. The 
interactive nature of the hydrology systems is certainly applicable to 
many other application areas including agronomy, forestry, and range 
land management to name only a few. EarthSat therefore recommends 
a consideration be given to broadening the scope of the hydrology activi- 
ties to include other discipline areas. 
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1.0 INTRODUCTION 


The application of interactive computer systems to hydrology is 
being accelerated by two rapidly advancing technologies; i.e. , hydrologi- 
cal simulation models, and remote sensing. Simulation models provide a 
"real world" mathematical viev/ of various hydrological processes, while 
remote sensing offers an opportunity to monitor hydrological processes 
in a here-to-fore impossible manner. Application of these two technolo- 
gies in an interactive system permits daily application of the most 

* 

basic of scientific study approaches; i.e., "observe, predict, observe." 

NASA's Goddard Space Fight Center (GSFC) has under development an 
interactive information processing system which has been termed AOIPS 
(Atmospheric and Oceanographic Information Processing System). AOIPS 
will permit rapid processing and manipulation of remote sensor data, 
ground-based observational data, and historical data, and will further- 
more permit more active operation of available hydrological simulation 
models using information derived from these sources. 

In order to exercise the capabilities Inherent in the AOIPS and to 
provide an effective demonstration of its application, a hydrology 
demonstration has been defined which, while obviously incomplete, will 
permit potential users to sit at a console and operate on a set of real 
data in a real and complex basin. 

The central focus of the hydrology demonstration is a geocoded data 
management system. The geocoded data base will accommodate a variety of 
types of input data: 

1. Remotely sensed data: 

a. LANDSAT/MSS 

b. SMS/VISSR 
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C. NIHBUS/ESHR 

2. Data products derived from space sensor data: 

a* Snow cover maps 

b. Water extent maps 

c. Rainfall maps 

d. Soil moisture maps 

e. Land use maps 

f. Flood plain boundary maps 

3. Ground truth data: 

a. Topographic ground elevation data 

b. USGS stream flow records 

c. Ground water level records 

d. Reservoir storage volume data 

e. Soil Conservation Service (SCS) snow water equivalent 
data 

f. SCS predicted stream flow data 

g. U.S. Army Corps of Engineers flood prone area maps 

In fact the geocoded data bases are designed to allow the application 
user to specify whatever data types he has potential interest in. 

The geocoded data management system demonstrated in the hydrology 
scenario allov;s for a wide range of processing of the data stored in the 
geocoded data bases. Processing options include: 

a. Change of scale 

b. MSS band combinations 

c. Contrast enhancement 

d. Edge enhancement 
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e. Registration of preprocessed multiple data sources 

f. Logical union and intersection of polygon overlays 

While it would be impossible to actually demonstrate all of these capa- 
bilities within the hydrology demonstration, the software capability to 
perform these algorithms has been provide.i under this contract. 

The geocoded data management system allov/s the user to process, 
store, and retrieve parameters suitable for input to hydrological models 
which could be operational on AOIPS in the future. Information stored 
in the data bases may be retrieved and displayed on the color CRT of the 
AOIPS GE Image 100. Color displays may be generated from multiple data 
sources by operator console commands. The data may be accessed at 
several levels of resolution, including: 

1. Natural resolution of the data source 

2. One square mile cell resolution 

3. Sub-basin or basin level resolution 

The hydrology demonstration will be performed using real data supplied 
fay GSFC for the Bear River watershed located in northwest Utah, south- 
west Idaho, and western Wyoming. 

The hydrology report begins by discussing the existing hydrology 
models currently in use today. The data management system provided as 
part of the hydrology demonstration is then discussed in Chapter 3. 
Chapter 4 together with Appendix A provides a user documentation of the 
data management system along with the various file structures and 
software- related information. Chapter 5 provides a copy of the hydrol- 
ogy demonstration booklet prepared for use during the hydrology dem- 
onstration. As such, much of the information presented in the first 
four chapters of this final report is summarized in Chapter 5. 
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Two appendices are provided as part of this final report. Appendix 
A contains all of the software system documentation necessary to use the 
software delivered under this contract. Appendix B provides a copy of 
the hydrology overview prepared early in the work of this contract. 
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2.0 HYOROLQ6Y APPLICATIONS ON AOIPS 


The river forecast problan posed itself as an Ideal hydrological 
application for AOIPS. The problan addresses questions of information 
needs for urban flood forecasting and seasonal water run-off forecasting 
which in turn are used for public disaster warnings, hydroelectric power 
management, and irrigation management. Additionally, the problem con- 
tains many elements which could best be served by ranote sensing and 
interactive computer processing. Finally it is noted that components of 
the river forecast problem are of joint interest to other appllcat'on 
scientists. Meteorology, agronomy, and rangeland management have 
interests in precipitation estimates and soil moisture budgeting, as 
well as the calculation of potential evapotranspiration. 

The design of the system to demonstrate the hydrology application 
dn AOIPS was constructed within the context of existing models and 
currently available data sources. An effort was made to design the 
system to supply the needs of the most complex models currently in use. 
It would be hoped that this design concept would accommodate most new 
input elements required by future models; it certainly should supply all 
of the needed elements of less complex existing models- 

The contract activities began by having EarthSat hydrologists/ 
meteorQlogists-l-^P''epare the 1980 Hydrologic Forecast situation: Where 
-the major deficiencies will exist and how they may be improved. This 
forecast reviewed the current state-of-the-art for hydrology and pro- 
jected a 1980 state-of-the-art. This forecast provided the perspective 
under which the AOIPS hydrology application work proceeded. 


Mr. Earl S. Merritt, Director, Food Resource Group. Mr. Richard 
Stanley, Staff Hydrologist (now with Far East Foundation). 
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Several of the major hydrology models currently in use will be 
briefly discussed in this chapter. The data requirements of these 


models will then be discussed in the light of how remotely sensed data 
may satisfy these requirements. 

0 

2.1 Existing Hydrology Models 

The purpose of hydrology models is to assess the effect of a 
rain or other event on the water flow rate within a watershed 
basin. The model itself is a mathematical abstraction and provides 
the researcher with the ability to examine the consequences of 
decisions such as channel modification or to predict the effects of 
snowmelt. In either case, the variations in stream flow can be 
estimated and these data used to make policy decisions. 

Each of the three models discussed in this section has two 
basic components: 

1. Estimation of stream or system inflow within each sub- 
basin of the watershed; 

2. Combination of these inputs to predict unit hydrographic 
readings at selected points within the stream system. 

Each of the models estimates mean precipitation over the basin area 
from weighted ground station data. These data are combined to 
estimate the area mean precipitation for the current time interval 
or event- Combined with parameters describing the ground condition 
of the basin (e.g. current soil moisture content, soil type, land 
use, slope of terrain, etc.), it is possible to estimate the amount 
of ground run-off entering the stream system from that sub-basin. 
The stream or river system is a mathematical network, each compo- 
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nent of which possesses certain characteristics, such as storage, 
through-put time, elevation, etc. Inflow from each sub-basin is 
entered into the network at that time interval. A certain amount 
of that component's inflow will "pass-through" and enter the next 
downstream element. This process is repeated for each interval 
over all network elements and the aggregate effects measured at 
hydrographs placed at various locations within the stream network. 
These hydrographic data can then be analyzed to measure the effects 
of decisions or events. 

2.1.1 NWSRFS Model 

The National Weather Service River Forecast System 
(NWSRFS) was developed by the Hydrologic Research Laboratory 
of NOAA to estimate river hydrographic (stage) levels. Es- 
timation of mean basin precipitation is performed by averaging 
the estimated precipitation for all grid points within the 
basin. A f.ine mesh or grid is superimposed over the basin and 
the assigned precipitation for each grid point is the weighted 
sum of the nearest reporting station in each quadrant sur- 
rounding the grid point. The lan.i phase of the hydrologic 
model estimates evapotranspiration potential (ETP) and actual 
evapotranspiration (ET). These and other calculated variables 
estimate the soil moisture status and infiltration. Remaining 
waters were accounted for as either surface run-off or inter- 
flow. These, combined with ground water storage, provide 
Inflow to the channel system. 

The channel system is segmented into a network of 
reaches or storage areas. The amount of water in each reach 
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is a function of the inflow and outflow* not only from the 
sub-basin precipitation but from upstream regions. The change 
in storage during an interval is proportional to the average 
interval outflow. The coefficients and constants used in the 
routing and transfer equations are determined using observed 
data. Station precipitation and hydrographic readings for 
specific events are used to optimize the model for the speci- 
fic watershed being studied. 

2.1.2 SSARR 

The Streamflow Synthesis and Reservoir Regulation model 
was developed by the Corp of Engineers to provide both opera- 
tional river forecasting and managsnent data as well as 
analyses needed for planning and design. The model is similar 
in many respects to the NWSRFS model discussed in Section 2.1.1. 
Specifically, basin precipitation is estimated from point 
observations. Additionally, the basic soil moisture param- 
eters were estimated using current soil moisture levels, 
infiltration, rainfall amount, and so on. The stream inflow 
from surface, sub-surface, and base flow are time-lagged from 
the occurrence of the event. The stream routing relations are 
based on the same assumptions as the NWSRFS model . The major 
difference arises in the inclusion of snowmelt parameters. 
Operational constraints for the Pacific Northwest require the 
annual snowmelt to be monitored. Consequently, temperature, 
elevation, total snowpack, and radiation models are used to 
estimate run-off from snowmelt since this is not directly 
measured and in some areas provides the major portion of 
stream inflow. 
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The HEC-1 flood hydrograph package was developed by the 

Corp of Engineers to estimate the flood potential of a basin 

system. Consequently, it Is applicable only to the single 

* 

storm event and cannot be used to monitor the basin over time. 
While the precipitation estimation is the same as the other 
tv/o models discussed above, the land phase is much more gene- 
ral, its sole purpose being to estimate run-off or stream 
inflow. The stream system routing mathematics is essentially 
identical to the SSARR model. 


2.2 Hydrology Model Data Recommendations 

Each of the models discussed in Section 2.1 has certain basic 
data requirements necessary to run it. In each case historic 
streamflows on station precipitation data are combined with static 
regional data to optimize specific coefficients for the model - 
Variables including land use, soils j impervious area, and vegetation 
cover are used to estimate parameters such as infiltration indices, 
basin time lags, etc. The historic data are input and the model is 
iteratively run until the prediction closest to observed data is 
obtained. 

Operationally it is necessary to initialize the model with the 
status of the stream system. Parameters such as current streamflow 
rate at each hydrograph can be used. Similarly, for those models 
with a snow melt component, an estimate must be made of the snow 
pack status. Meteorological parameters are required several times 
a day to provide accurate estimates of the environmental factors. 
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specifically, precipitation estimates, temperature, wind, and 
radiation measurements are used to estimate evapotranspiration 
potential, mean precipitation, etc. These data are in turn used to 
modify the hydrologic status of the basin systan within the frame- 
work of the models discussed above. 

2.3 Data Requirements Satisfied By Remotely Sensed Data 

Many of the data requirements for the existing hydrologic 
models can be supplied through the uses of remotely sensed data. 

Land use, soils, and vegetation information can be obtained using 
high resolution imagery. Additionally, sufficiently detailed land 
use data can be used to supply ground and vegetation cover informa- 
tion. From these data, initial estimates of infiltration indices 
and other soils surface parameters can be inferred. 

Probably the greatest potential contributions of remote sensing 
are in the areas of precipitation and soil moisture estimation and 
area monitoring.. As currently Implemented, each model estimates 
area precipitation based on observations at selected stations in 
the basin area. In the case of the NWSRFS discussed in Section 2.1, 
an estimate of point precipitation is made by a weighted sum of 
surrounding station observations. The weights used are proportional 
to the distance between the points in the observing station network. 
Given a relatively dense network of >'eporting stations this approach 
works reasonably well; however, in relatively inaccessible regions 
or in areas where the network is sparse, the accuracy of this 
technique is poor. One solution which can be used is to estimate 
the location and amount of precipitation from meteorological 
satellite data such as SMS visible and infrared Imagery. These 
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data, obtained repetitively during the day, can be analyzed as to 
cloud type and brightness. These descriptors are then used to 
empiricany estimate precipitation from that cloud mass. 

Similarly, It is possible to use satellite Imagery to monitor 
the snow pack. Area measuronents of snow cover can be combined 
with topological data to estimate snowmelt potential. As snovmielt 
begins, satellite data can be used to monitor the melt process. 
These observations can be used to refine the operational model 
estimates and used in flood prediction models, 

2.4 A0IP5 Capability as Applied to the Needs of the Hydrology 

Application 

In the initial phases of the contract work, the usefulness of 
AOIPS to the hydrology application science appeared to be prin- 
cipally as a system to process raw data into a form acceptable for 
use by existing hydrology models- For example, the AOIPS system 
could be used to. transfer SMS data from its raw form (digital 
imagery) to a form accepted by NWSRFS (mean basin precipitation). 

As EarthSat scientists gained experience in using AOIPS hardware, 
it became apparent that this important function may not ultimately 
be the principal use of AOIPS by hydrologists. The interactive 
capability to display, overlay, and, in general, to analyze digital 
data, tied directly to a geocoded data base which contained all 
hydrologlcally-related parameters, promises to be an extremely 
powerful tool for the research hydrologist to use In improving 
existing models and in developing new models- This marriage of 
display capabilities with geocoded infomation data files contain- 
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ing a variety of data types provides the researcher with the capa- 
bility to easily investigate spatial and temporal relationships 
between observed phenomena. The interactive nature of the system 
will allow the user to query the information files for specific 

4 

types of events, and "track" the events as they are processed by 
the AOIPS system and then eventually by the large river forecast 
hydrology models. This type of application user "hands-on" experi- 
ence should result in valuable improvements in the understanding of 
hydrol ogy-rel ated phenomena. 
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3-0 HYDROLOGY SCENARIO 


During the initial system definition phases of this contract it was 
decided that the system design would be prepared in light of the ultim- 
ate capability which AOIPS could provide to the hydrology user. As 
such, the system demonstration prepared under this contract would repre- 
sent a single component of a larger system. The advantages of this 
design concept are: 

1. The ultimate and complete utility of the system is apparent 
from the start; 

2. The system design remains flexible and versatile so that as 
yet unknown or unexpected application problems may be easily 
accommodated; 

3. The system becomes usable to the application scientist long 
before it is fully completed; 

4. Implementation of design features may be prioritized so that 
the most important features to the application scientists are 
implemented first; 

5. Complete implementation of the hydrology applications system 
may be accomplished within the framework proposed in the 
design, thus minimizing any reprogramming effort on future 
contracts. 

In the first section of this chapter, an overview of the entire 
system is provided, the components of the hydrology file are discussed, 
and capabilities of both the present and future potential systems are 
finally described. 
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3.1 System Overview 


Earth Satellite Corporation hydrologists began by preparing an 
AOIPS hydrology scenario. Within this work, a number of currently 
existing major hydrology models were studied with particular regard 
to input data requirements. Emphasis was placed on identifying 
those hydrology parameters which are currently available (or pos- 
sibly available in the future) from remotely sensed data. The 
hydrology applications data processing system was designed with the 

intent of being capable of processing all of the input data require- 

*-1 

ments needed by the most sophisticated hydrology models in exist- 
ence today. This type of design allows all less sophisticated 
hydrology model data requirements to be provided as a subset of a 
complete system. 

Two immediate questions have to be resolved concerning the 
system design. First, since the system required storing geocoded 
information a particular grid system had to be adopted. Second, 
since input data at a variety of scales and projections would have 
to be processed, a "standard resolution element" had to be estab- 
lished; staff hydrologists agreed that the World Meteorological 
Organization (WMO) grid system provided an excellent grid framework 
for storing the geocoded information. The WMO grid is well defined 
for all parts of the globe and is easily adapted to different size 
resolution elements. 

The standard cell resolution element was defined to be one 
square mile. The one square mile cell v/as agreed upon because it 
provided a good compromise between the natural resolution sizes of 
the various types of input data. The problem existed, however, 
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that the smallest resolution unit accepted by any of the hydrology 
models was the sub-basin unit. Depending upon application, a sub- 
basin may be as small as a single stream basin or as large as an 
entire river basin. The concept of dual data files at different 
resolutions emerged as the natural solution of this problem. The 
first data file stored at the one square mile cell resolution 
served as an intermediate step between the natural resolution of 
the input data and the final required resolution of the sub-basin 
level. In this case, a sub-basin is defined as a specific aggrega- 
tion of any number of one square mile cells. At this point, the 
fundamental design features of the information processing system 
had been defined: 

1. All initial processing of input data would be performed 
at whatever unit resolution was most logical for that 
particular data type; 

2. Initially processed data would be converted and stored at 
the intermediate one square mile cell level. This may 
require aggregating data in the case of LANDSAT/MSS- 
derived inputs, or spatial interpolation of data as in 
the case of point weather station data; 

3. The one square mile cell data would be aggregated upward 
to the sub-basin level with the sub-basin being defined 
by the application user. 

In addition to considering the spatial properties of data 
storage, it was necessary to also consider the temporal properties 
of the data to be processed. As noted in the AOIPS hydrology 
scenario paper (see Appendix B). it is necessary to provide the 
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hydrological models with slowly varying data such as soil type, 
land use cover, and porosity maps as well as the rapidly varying 
data such as maximum and minimum temperatures and precipitation. 
Since it would be inefficient to maintain all of the slowly varying 
data within the same data file as the rapidly varying data, it was 
decided to maintain tv/o types of data files: 

1. An archive file with all of the slowly varying data. 

2, A daily file with only information related to a specific 
observation date. 

In total, there would be four separate data files maintained on the 
hydrology data management system on AOIPS: 

1. Cell Archive - containing only slowly varying information 
entered at the one square mile cell level. 

2. Cell Daily - containing only daily inputs entered at the 
one square mile cell level. 

3. Basin Archive - containing all slowly varying information 
aggregated up to the basin level from the sub-level. 

4. Basin Daily - containing all daily inputs aggregated up 
to the basin level from the cell level. 

In reality, the only difference between the archive data files 
and the daily data files is in the meaning associated with the 
numbers stored in the data files and the frequency with which the 
files are updated with new information. The same file structure is 
used for both sets of files. 

3.2 Hydrology Scenario Components 

Figure 3.1 shows the overall flow of the entire geocoded 
hydrology data management system. As is indicated on Figure 3.1, 
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the entire system includes the AOIPS hardware as the central data 
processor and manager with interfaces on both input and output to a 
main-frame computer system. 

Depending upon data type, the original data enters the AOIPS 
system either directly or after some specialized pre-processing 
(block A on Figure 3.1). Data pre-processing may be performed for 
a variety of purposes: 

1. Reformatting original data; 

2, Changing data projections; 

3- Extracting data windows of interest. 

Basically, any operation not requiring an interactive capability 
designed to reduce, transform, or edit the original data may be 
performed at the pre-processing step. 

After completion of any necessary data preprocessing, the data 
enters the Hydrology Data Management System on AOIPS (block B on 
Figure 3.1). It is at this point. where most of the interactive 
data processing is performed. Implementation of those portions of 
the AOIPS hydrology system to be demonstrated under this contract 
were therefore selected from this activity. Four primary functions 
were performed by the AOIPS Data Management System: 

1. Data reduction - Any necessary data reductions or trans- 
formations are performed to prepare the data for entry 
into the geocoded cell level data base use. 

2. Spatial registration - Data is registered to the geocoded 
data base grid system through the use of ground control 
points. 
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Data entry - Data items are entered into the geocoded 
cell level data base use. Where necessary data is aggre- 
gated or interpolated to the one-mile cell level prior to 
entry. 

4. Cell data preview - Cell level data file entries may be 
edited, displayed, overlayed, and updated. 

Figure 3.2 shows the expanded view of the Hydrology Data Management 
System. The type of processing performed at the data reduction 
step is seen to be very "data type specific." New data types may 
be easily incorporated to the hydrology system by simply providing 
additional specialized data processing options at this point. The 
geocoded data files are sufficiently general to allow the user to 
specify what information is to be stored in the files once it 
reached the "data entry stage." 

The final function performed by the Hydrology Data Management 
System is the cell level preview and edit function. Any data which 
has been stored in the geocoded data files may be retrieved and 
displayed on the one square mile cell level. Execution time options 
are available to allow the users to selectively display information 
within the data files. 

Block C on Figure 3.1, shows the next step in the processing 
of data by the AOIPS Hydrology Scenario. Once data has been entered 
into either the archive or daily file at the one square mile cell 
level it must be aggregrated up to the sub-basin level. Data 
aggregration would be performed using a variety of algorithms 
depending on the type of data being aggregated. The basin archive 
and basin daily files would then contain all of the data necessary 
to drive the main frame hydrology models. The aggregated data 
could also be edited and updated at the basin levels 
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Block 0 on Figure 3.1, would provide the final interface to 
the hydrology basin models. The only function performed by the 
basin model interface would be to format the data contained v/ithin 
the basin archive and basin daily files to a form acceptable to the 
particular hydrology model being used. 

As an example of how the AOIPS Water Resources Data Management 
System could be used to process data, consider the following sequence 
of processing steps which might be applied to input SMS data tapes: 

1) Extract SMS window of interest from the master data tape 
(Block A on Figure 3-1). 

2) Use METPACK to identify ground control points (Block A). 

3) Display SMS window on the Image-100 and locate clouds 
with the cursor (Block B). 

4) Identify cloud types and make precipitation estimates 
(Block B). 

5) Enter cloud data and precipitation estimates into the 
Cell Daily Database (Block B). 

6) Use the spatial distribution of the cloud cell data to 
drive the net solar radiation calculation in the Over 
Land Phase of the Hydrology Basin models. 

7) Use the precipitation estimates for each cell to drive 
the potential evapotranspiration calculation in the Over 
Land Phase of the Hydrology Basin models. 

8) Store the results of the Over Land Phase calculation 
performed by the Hydrology Basin models back in the Cell 
Daily Database (Block B). 

9) Aggregate the Over Land Phase results to the basin level 
and store in the Basin Daily Database (Block C-1). 
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Aggregate the precipitation estimates to the basin leve’ 
and store in the Basin Daily Database (Block C-1). 

11) Format the basin level data from the Basin Daily Database 
for use by the Channel Routing Phase of the Hydrology 
Basin models (Block D). 

3.3 System Capabilities 

Several important features of this design should be noted: 

1. New types of information may be easily accommodated with 
a minimum amount of new programming. 

2. Users have an opportunity to study the impact of hydro- 
logical events at four different levels; original input 
data resolution, one square mile cell resolution, basin 
resolution, and finally at the hydrology model "resolution." 

3. New models may be tested by entering "pseudo" data at any 
appropriate point in the system. 

4. The hydrology basin model interface allows the user to 
easily compare the results of different hydrology basin 
model s. 

As mentioned earlier the implementation of the AOIPS hydrology 
system for the demonstration was directed towards portions of the 
Hydrology Data Management System. The ability to process SMS data, 
LANDSAT data, and topographic data was developed to demonstrate 
those features of the system. Additionally, the ability to gene- 
rate the cell level data files as well as to enter, retrieve, 
display, and overlay information from those files was developed for 
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the demonstration. The ability to process other data types includ- 
ing meteorological weather station data, historical ground truth 
data, stream gauge records and other point source data have not yet 
been developed. 

3.4 WMO Grid 

A grid mesh system which is frequently used in operational 
meteorology was selected for this study as offering a convenient 
system in which to manage the computations and data manipulations. 
While some aspects of the grid definition might conveniently have 
been modified for the current application, this was not done, 
thereby allowing for future expansion to a global scale and remaining 
compatible with the format of possible future sources of input 
data. 

The grid mesh system is rectangular to a polar stereographic 
projection of the northern hemisphere. The spacing between successive 
grid points at middle latitudes is about -1 nautical miles. The J- 
axis is parallel to the great circle defined by 100 degrees east 
longitude and 80 degrees west longitude. The north pole is at (I = 
3201, J = 3201). The equations relating latitude (Lat) and longi- 
tude (Lon) to I and 0 are: 

I = 3201 + R cos A 
0 = 3201 + R sin A 

where 

R = 3120.4375 tan ((90° - Lat)/2) 

A = 10 - Lon 

and longitude is defined as positive in the eastern hemisphere and 
negative in the western. 


3.5 Importance of the Geocoded Grid System Concept 


Throughout the description of the Hydrology Senario, reference 
was made to the geocoded data management system. During the design 
phases of the Hydrology Scenario it was decided that the World 
Meteorological Organization (WMO) grid was to be used as the stan- 
dard frame of reference. Advantages of using the WMO grid include: 

1. Uniquely defined globally. 

2. Easily related to latitude and longitude. 

3. Regularly spaced and shaped grid cells. 

4. Size of unit cell easily adaptable to users needs. 

5. Cells easily specified by a triple index (I,0,K). 

6. Telescoping resolution for varying input data. 

It is extremely important to point out the central role which this 
type of geocoded grid system plays in the entire design. Any type 
of information management system using geocoded information must 
establish some type of geocoded frame of reference. In a true 
geocoded information management system, the frame of reference 
provides the frame work for storing and retrieving all of the 
geocoded information. In the Hydrology Scenario the grid system 
provides the basic indices used to reference all of the data, The 
ultimate flexibility and utility of the Hydrology Scenario is 
closely tied to the capability to reference a large variety of data 
types through a single grid system. 
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4.0 HYDROLOGY SCENARIO DOCUMENTATION 


This section describes the physical structure of the hydrology data 
base and its environment and in conjunction with the software documenta- 
tion in Appendix A provides a user's manual for both system generation 
and hydrology applications. The discussion of file structures is by 
necessity directed toward persons with a background in data processing. 
System generation is also an area which is best left to a computer 
professional; however, system generation documentation has been provided 
such that it could be accomplished by a person with a user oriented 
background . 

4.1 System Generation Documentation 

4.1.1 System Environment 

The hydrology data management system was designed to 
operate on a PDF 11/70 or 11/45 under the RSX-ll-D operating 
system with a minimum of 64K main memory. Mass storage require- 
ments will vary with each application, but for most purposes a 
single RP04P 88 megabyte disc pack will provide adequate 
storage for software and data files. All data files must 
reside on the same volume in order to be processed by the 
system software. Source, object, and task modules may reside 
on a separate volume if necessary. 

All source modules are written in FORTRAN for compil- 
ation on PDF's FORTRAN IV-PLUS compiler. Object modules may 
be interchangeable among POP 11 's operating under the same 
system but recompilation is recommended. Task modules should 
never be transferred between systems. As the data management 


system has neither an executive of its own nor any interdepen- ; 

dent tasks, there is no need for any shareable global areas. 

Under normal circumstances, there is no need for the user to 
operate under a privileged UIC. 

* 

4.1.2 File Structure > 

The hydrology data base consists of four files, a label 
and an index file for overhead functions, and an archive and a 
daily file for actual data storage. Overhead type files have 
a fixed format whereas the data files may be varied with each 
application. 

The label file is transparent to the user but contains 
information necessary for processing the other three files. 

The file is named NAME.LBL, where NAME represents a one- to 
nine-character data base name which conforms to the standards 
of POP's file control services. The label file contains three 
records j one each for the index, archive, and daily files, and is 
accessed sequentially. The format of a label record is out- 
lined in Table 4-1. The index file defines a rectangular area 
indexed by I,J coordinates which contain the entire water- 
shed. This random access file contains one 8-byte record for 
each I,J cell within the rectangle. The file is sorted first 
by J coordinate then by I coordinate, both in ascending order. 

Additionally, the file contains one header record v;liich defines 
the limits of the rectangle. Both index record formats are 
outlined in Table 4-2. The index record for a given I,J can 
be located using the following equation: 



LABEL RECORD 


BYTE 

POSITIONS 

CONTENTS 

FORMAT 

0-3 

NUMBER OF RECORDS 

BINARY 

4-5 

RECORD LENGTH 

BINARY 

6-23 

FILE NAME 

ASCII 


TABLE 4-1 
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INDEX RECORDS 


HEADER RECORD 


BYTE 


POSITIONS 

CONTENT 

FORMAT 

0-1 

MINIMUM I VALUE 

BINARY 

2-3 

NUMBER OF I VALUES 

BINARY 

4-5 

MINIMUM 0 VALUE ‘ 

BINARY 

6-7 

NUMBER OF J VALUES 

BINARY 


POINTER RECORD 


BYTE 

POSITIONS 

CONTENT 

FORMAT 

0 

BASIN NUMBER - K=1 

BINARY 

1 

BASIN NUMBER - K=2 

BINARY 

2 

BASIN NUMBER - K=3 

BINARY 

3 

BASIN NUMBER - K=4 

BINARY 

4-7 

POSITION OF DATA RECORD 
FOR K=1 IN ARCHIVE OR DAILY 
FILES 

BINARY 


TABLE 4-2 


^^*^nuniber 


== (J-J . ) X NUHI + (I-IMIN) + 2 
imn 
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The index file name is constructed by appending a type quali- 
fier of IDX to the data base name. 

The archive file is one of the tv/o direct access data 
files in the data base and is used to store data which remains 
constant with time. It contains four records for each index 
record which indicates a populated I,J cell. The archive 
length may be varied at creation but must be greater than 14 
bytes. An 80- byte length provides compatibility v/ith the RSX 
text editor. The first record in the archive file is a header 
recorder which is not used. It is included only to provide 
conformity with the daily file format. The format of the 
archive data record is described in Table 4-3. Each archive 
record contains an offset pointer which when added to the 
current record number indicates the record number of the next 
populated K cell within the same basin. The archive file name 
is constructed by appending a type qualifier of ARC to the 
data base name. 

The daily file is the second random access data! file 
and data base, and is used to store temporal information. The 
organization is identical to that of several concatenated 
archive files; one for each date. Each date contains the same 
number of records as the archive file. In addition to the 
data records the daily file contains one header record which 
is described in Table 4-4, To locate the data record for a 
given I,J of a given date, the following equation is used: 


ARCHIVE DATA RECORD 


BYTE 

POSITIOHS 

CONTENTS 

FORMAT 

0-3 

I COORDINATE 

ASCII 

4-7 

J COORDINATE 

ASCII 

8-9 

K CELL NUMBER 

ASCII 

10-n 

BASIN NUMBER 

ASCII 

12-13 

POINTER TO NEXT RECORD 
WITHIN BASIN 

BINARY 

14-17 

GROUND COVER - WATER 

ASCII 

18-21 

GROUND COVER - HARSH 

ASCII 

22-25 

GROUND COVER - FOREST 

ASCII 

26-29 

GROUND COVER - VEGETATION 

ASCII 


TABLE 4-3 
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DAILY RECORDS 


HEADER RECORD 


BYTE 


POSITIONS 

CONTENT 

FORMAT 

0-3 

NUMBER OF RECORDS PER DATE 

BINARY 

4-5 

NUMBER OF DATES 

BINARY 

6-7 

POSITION OF LAST DATE ENTERED 

BINARY 

8-9 

» 

DATE #1 (ODD) 

BINARY 

* 

68-69 

* 

• 

DATE #31 (DDD) 

« 

« 

BINARY 


DATA RECORD 


BYTE 

POSITIONS 

CONTENT 

FORMAT 

0-3 

I COORDINATE 

ASCII 

4-7 

J COORDINATE 

ASCII 

8-9 

K CELL NUMBER 

ASCII 

10-11 

BASIN NUMBER 

ASCII 

12-13 

POINTER TO NEXT RECORD 
WITHIN BASIN 

BINARY 

14-19 

JULIAN DATE (YYDDD) 

ASCII 

20-25 

PRECIPITATION 

ASCII 


TABLE 4-4 
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REC ^ = (IREC) + (NDATE-1) x NRECPD [4-2] 

number 

where IREC is the record number obtained from the index file, 
NDATE is the position of the date in the daily file, and 
NRECPD is the total number of records for each* date in the 
daily file. The pointer to the next record within the basin 
is identical to its archive file counterpart. The daily file 
name is constructed by appending a type qualifier of DLY to 
the data base name. 

4.1.2 System Generation 

This discussion of the data base generation procedure 
assumes all data management software has been successfully 
compiled and task built, and that a properly initialized RP04P 
disk pack has been mounted on an RD: device. Complete docu- 
mentation for all softv\iare modules referred to in this section 
can be found in Appendix A. 

The only pre-processing function required before file 
generation is the definition of the watershed boundaries and 
the boundaries of each sub-basin. These are defined by the 
maximum and minimum I and J coordinates contained within the 
watershed and by the latitude and longitude of each vertex of 
the sub-basin polygons. 

Once the watershed boundaries are defined the index 
file may be created by executing the program CINDEX. This 
requires the maximum and minimum 1,0 and the data base name as 
inputs. After completion there should exi.st an index file 
which contains a header record describing the file structure 


4-8 


and the correct number of dummy index records. CINDEX also 
creates the label file and the index file label. 

The next task is to fill in the basin keys of the index 
file. This is accomplished by running the program POLYB. 

This requires the latitude and longitude coordinates of each 
vertex for each sub-basin in the watershed. POLYB converts 
these coordinates to UK's, constructs the sub-basin polygon, 
and inserts the corresponding basin keys for each K-cell 
within the sub-basin. After completion the index file com- 
pletely describes the structure of the watershed. 

The creation of the data files may now be accomplished 
by running the program CDATA. This program will create either 
the archive or the daily file or both simultaneously. The 
only inputs required are the record lengths for each file and 
the number of dates desired in the daily file. All other 
information is extracted from the completed index file. The 
completed files will contain data records with UK and the 
basin numbers filled in. The daily file will contain a com- 
pleted header record. Label entries will also be created for 
each file. 

At this point it is advisable to run the program DISPLAY 
to produce an image map of the basin keys. This map can be 
compared with the known watershed structure to verify the 
structure contained in the index, archive, and daily files. 


The final step in the file creation procedure is to run 
the program NBASIN which will traverse the archive and daily 
files and insert the pointers which indicate the position of 
the next data record within the same basin. These pointers 
are useful in aggregation of data from the cell level to the 
basin level. After completion of NBASIN» the data base is 
ready for data insertion. 

4.2 Users Guide Documentation 

This section covers the handling of remotely sensed data for 
insertion into the data base and the retrieval of that data in 
image format. The handling of SMS imagery requires pre-processing 
by the METPAK system to select the desired window and obtain 
registration information. LANDSAT classification data must be 
generated using the Image 100 System as supplied by General Elec- 
tric. The flow of data through the data management system is out- 
lined in Figure 4.1 . 

4,2.1 Methods of Data Insertion 

Two options are presently available for insertion of 
data into the data base. These options are: 

1. Derived precipitation estimates from SMS. 

2. Ground cover classification from LANDSAT. 

More important is the fact that these options provide 
the basic capacity for handling remotely sensed data at various 
levels of resolution. This basic capability provides a foun- 
dation which may be readily expanded upon to provide large 
scale processing capability. 

BLANK NOT FIL 
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HYDROLOGY DATA MANAGEMENT SYSTEM 



FIGURE 4.1 DATA FLOW THROUGH THE AOlPS HYDROLOGY 
DATA MANAGEMENT SYSTEM 


t 

















4. 2. 1.1 Precipitation Data 


The derivation of precipitation estimates 
requires that the user have an SHS image, v/indowed 
and registered by METPAK, on the screen of the Image 
100. The first step is to run the program POLYGO 
(Section A-3.8) outlining all cloud polygons of those 
cloud types which produce precipitation. Once this is 
accomplished the polygon information can be processed 
by the program PLYDMP (Section A-4.6). When option one 
is selected the user will be prompted for cloud type 
information from which precipitation estimates are 
derived. This information is dumped to a disk file for 
insertion into the data base by the program PLYRD 
(Section A-4.7) . 

PLYRD requires the image registration informa- 
tion obtained from METPAK. Once the image has been 
registered to the WMO grid, processing simply involves 
the insertion of the previously defined precipitation 
estimates into the data base daily file at the I,J cell 
level . 


4. 2. 1.2 LANDSAT Classification Data 

Derivation of ground cover estimates requires 
that a LANDSAT image of the watershed area has been 
previously classified by the Image 100 system, and the 
results are stored on the theme planes of the Image 100. 

The first step is to convert the theme data 
into a form which can be accepted by the program ERTS200 
(Section A-4.9). This is accomplished by running the 
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program PLYDMP, specifying option number tv;o. This 
will create a disk file of the theme information. 

Next ERTS200 may be run to register the image 
and process the classification data. The REGISTER 
option must be specified first to register the image to 
the WHO grid. After registration is completed the 
INSERT option may be selected to aggregate the data to 
the K-cell level and insert it into the data base 
archive file. 

4.2.2 Methods of Data Retrieval 

The capability to display any parameter in both the 
archive and daily files is provided by the program DISPLAY 
(Section A-4.8). The user specifies the file to be displayed 
(archive or daily), the parameter to be displayed, and the 
maximum and minimum parameter limits. The output is in the 
form of a binary map with all cells in whicn the data parame- 
ter falls within the specified limits turned on and all other 
cells turned off. 

This provides the hydrologists with the ability to 
obtain an instant overview of any data base parameter. It is 
especially useful in the delineation of areas subjected to 
extreme conditions (i.e., drought or heavy rainfall). Also, 
by overlaying several of these maps, a graphic display of the 
correlation between data parameters may be achieved. 
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5.0 AO I PS HYDROLOGY DEMONSTRATION 


The emphasis throughout this Contract was directed toward developing 

a demonstration of the AOIPS Water Resources Data Management System. As 

* 

partial fulfillment of the Contract deliverable, Earth Satellite Corporation 
performed a demonstration of the Water Resources Data Management System on 
August 25, 1976. A booklet was prepared for use in that demonstration to 
provide a synopsis of the work being performed and to show selected examples 
of the products being demonstrated. Chapter 5 is a reproduction of the 
material contained in the booklet. 
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5.1 INTRODUCTION 


Earth Satellite Corporation* working under NASA Goddard Space 
Flight Center Contract No. NAS5-22894, has designed a geocoded data 
management system applicable for hydrological analysis,' The central 
features accommodated by the system design include: 

1. Ability to process a variety of data types related to hydro- 
logical parameters; 

2. Ability to store and retrieve data within a common framework 
for all data types; 

3. Ability to analyze spatial and temporal relationships between 
hydrologically related parameters through video displays and 
overlays; 

4. Ability to drive existing main-frame hydrologic models from 
outputs of the system. 

The emphasis throughout the contract was to demonstrate the utility 
of the Atmospheric and Oceanographic Information Processing System 
(AOIPS) for hydrological applications. Within that context, the geo- 
coded hydrology data management system was designed to take advantage of 
the interactive capability of AOIPS hardware. Portions of the system 
which best demonstrate the interactive nature of the hydrology data 
management system were implemented on the AOIPS. A hydrological case 
study was prepared using all data supplied by GSFC for the Bear River 
watershed located in northwest Utah, southeast Idaho, and western Wyoming. 
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5.2 HYDROLOGY APPLICATIONS ON AOIPS 


The river forecast problem posed itself as an ideal hydrological 
application for AOIPS. The problem addresses questions of information 
needs for urban flood forecasting and seasonal water run-off forecasting 
which in turn are used for public disaster warnings, hydroelectric power 
management, and irrigation management. Additionally, the problem con- 
tains many elements which could best be served by remote sensing and 
interactive computer processing. Finally it is noted that components of 
the river forecast problem are of joint interest to other application 
scientists. Meteorology, agronomy, and rangeland management have 
Interests in precipitation estimates, and soil moisture budgeting, as 
well as the calculation of potential evapotranspiration. 

The design of the system to demonstrate the hydrology application 
on AOIPS was constructed within the context of existing models and 
currently available data sources. An effort was made to design the 
system to supply the needs of the most complex models currently in use. 
It would be hoped that this design concept would accommodate most new 
Input elements required by future models, and certainly should supply 
all of the needed elements of less complex existing models. 

5.2.1 Existing Hydrology Models 

The purpose of hydrology models is to assess the effect of a 
rain or other event on the water flow rate within a watershed 
basin. The model itself is a mathematical abstraction and provides 
the researcher with the ability to examine the consequences of 
decisions such as channel modification or to predict the effects of 
snowelt. In either case, the variations in stream flow can be 
estimated and these data used to make policy decisions. 
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Each of the three models discussed in this section has two 
basic components: 

1, Estimation of stream or system inflow with each sub-basin 
■of the watershed; 

2. Combination of these inputs to predict unit hydrographic 
readings at selected points within the stream system. 

Each of the models estimates mean precipitation over the basin area 
from weighted ground station data. These data are combined to 
estimate the area mean precipitation for the current time interval 
or event. Combined with parameters describing the ground condition 
of the basin (e.g. current soil moisture content, soil type, land 
use, slope of terrain, etc.), it is possible to estimate the amount 
of ground run-off entering the stream system from that sub-basin. 
The stream or river system is a mathematical network, each compo- 
■ nent of which possesses certain characteristics, such as storage, 
through-put time, elevation, etc. Inflow from each sub-basin is 
entered into the network at that time interval. A certain amount 
of that component's inflow will "pass-through" and enter the next 
downstream element. This process is repeated for each interval 
over all network elements and the aggregate effects measured at 
hydrographs placed at various 1' ations within the stream network. 
These hydrographic data can then be analyzed to measure the effects 
of decisions or events. 

5.2.2 Hydrology Model Data Requirements 

Each of the currently existing hydrology models has certain 
basic data requirements necessary to run them. In each case his- 
toric stream flows on station precipitation data are combined with 
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static regional data to optimize specific coefficients for the 
model. Variables including land use, soils, impervious area, 
vegetation cover are used to estimate parameters such as infil- 
tration indices, basin time lags, etc. The historic data are input 
and the model iteratively run until the prediction closest to 
observed data is obtained. 

Operationally it is necessary to initialize the model with the 
status of the stream system. Parameters such as current stream 
flow rate at each hydrograph can be used. Similarily for those 
models v/ith a snow melt component an estimate must be made of the 
snow pack status. Meteorological parameters are required several 
times a day to provide accurate estimate of the environmental 
factors. Specifically, precipitation estimates, temperature, wind, and 
radiation measurements are used to estimate evapotranspiration poten- 
tial, mean precipitation, etc. These data are in turn used to modify 
the hydrologic status of the basin system within the framework of the 
models discusse’d above. 

5.2.3 Data Requirements Satisfied By Remotely Sensed Data 

Many of the data requirements for the existing hydrologic 
models can be supplied through the uses of remotely sensed data. 

Land use, soils, and vegetation information can be obtained using 
high resolution imagery. Additionally, sufficiently detailed land 
use data can be used to supply ground and vegetation cover informa- 
tion. From these data, initial estimates of infiltration indices 
and other soils surface parameters can be inferred. 
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Probably the greatest contributions of remote sensing are in 
the areas of precipitation estimation and area monitoring. As 
currently implemented by existing hydrology, each model estimates 
area precipitation based on observations at selected stations in 
the basin area. Estimates of point precipitation are made by a 
weighted sum of surrounding station observations. The weights used 
are proportional to the distance between the point in the observing 
station. Given a relatively dense network of reporting stations 
this approach works reasonably well; however, in relatively inac- 
cessable regions or in areas where the network is sparce, the 
accuracy of this technique is poor. One solution which can be used 
is to estimate the location and amount of precipitation from meteoro- 
logical satellite data such as SMS visible and infrared imagery. 

T.his data obtained repetitively during the day can be analyzed as 
to cloud type and brightness. These descriptors are then used to 
empirically estimate precipitation from that cloud mass. 

Similariiy it is possible to use satellite imagery to monitor 
the snow pack. Area measurements of snow cover can be combined 
with topological data to estimate total water equivalent. As snow 
melt begins satellite data can be used to monitor the melt process. 
These observations can be used to refine the operational model 
estimates and use in flood prediction models. 


t 
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3 HYDROLOGY SCENARIO 


5.3.1 System Overview 

Earth Satellite Corporation hydrologists began by preparing an 
AOIPS hydrology scenario. Within this work, all the currently 
existing major hydrology models were studied with particular regard 
to input data requirements. Emphasis was placed on identifying 
those hydrology parameters which are currently available (or pos- 
sibly available in the future) from remotely sensed data. The 
hydrology applications data processing system was designed with the 
intent of being capable of processing all of the input data require- 
ments needed by the most sophisticated hydrology models in exist- 
ence today. This set of design allows all less sophisticated 
hydrology model data requirements to be provided as a subset of a 
complete system. 

Two immediate questions have to be resolved concerning the 
system design. First,, since the system required storing geocoded 
information a particular grid system had to be adopted. Second, 
since input data at a variety of scales and projections would have 
to be processed, a "standard resolution element" had to be estab- 
lished; staff hydrologists agreed that the World Meteorological 
Organization (1^0) grid system provided an excellent grid framework 
for storing the geocoded information. The liHO grid is well defined 
for all parts of the globe and is easily adapted to different size 
resolution elements. 

The standard cell resolution element was defined to be one 
square mile. The one square mile cell was agreed upon because it 
provided a good compromise between the national resolution sizes of 
the various types of input data. The problem existed, however. 


5-7 


that the smallest resolution unit accepted by any of the hydrology 
models was the sub-basin unit. Depending upon application, a sub- 
basin may be as small as a single stream basin or as large as an 
entire river basin. The concept of dual data files at different 
resolution emerged as the natural resolution of this problem. The 
first data file stored at the one square mile cell resolution 
served as an intemediate step between the natural resolution of 
the input data and the final required resolution of the sub-basin 
level. In this case, a sub-basin is defined as a specific aggrega- 
tion of any number of one mile cells. At this point, the fundamen- 
tal design features of the information processing system had been 
defined: 

1. All initial processing of input data would be performed 
at whatever unit resolution was most logical for that 
particular data type; 

2. Initially processed data would be converted and stored at 
. the intermediate one square mile cell level. This may 

require aggregating data in the case of -LANDSAT/ MSS- 
derived inputs, or spatial interpolation of data as in 
the case of point weather station data; 

3. The. one square mile cell data would be aggregated upward 
to the sub-basin level with the sub-basin being defined 
by the application user. 

In addition to considering the spatial properties of data 
storage, it was necessary to also consider the temporal properties 
of the data to be processed. As noted In the AOIPS hydrology 
scenario paper it is necessary to provide the hydrological models 
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with slowly varying data such as soil type, land use cover, and 
porosity maps as well as the rapidly varying data such as maximum 
and minimum temperatures and precipitation. Sine*' it would be 
inefficient to maintain all of the slowly varying data within the 
same data file as the rapidly varying data, it was decided to 
maintain tv/o types of data files: 

1 , An archive file with all of the slowly varying data. 

2. A daily file with only information related to a specific 
observation date. 

In total, there would be four separate data files maintained on the 
hydrology data management system on AOIPS: 

1. Cell Archive - containing only slov/ly varying information 
entered at the one square mile cell level, 

2. Cell Daily - containing only daily inputs entered at the 
one square mile cell level. 

3. Basin Archive - containing all slowly varying information 
•aggregated up to the basin level from the sub-level. 

4. Basin Daily - containing all daily inputs aggregated up 
to the basin level from the cell level. 

In reality, the only difference between the archive data files 
and the daily data files is in the meaning associated with the 
numbers stored in the data files and the frequency with which the 
files are updated with new information. The same file structure is 
used for both sets of files. Figure 1 shows an overview of the 
hydrology scenario design. 
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FIGURE 5-1: HYDROLOGY SCENARIO DESIGN 






5.3.2 System Capabilities 

Several important features of this design should be noted; 

1. Nev/ types of information may be easily acconraodated with 
a minimum amount of new programming. 

2 . Users have an opportunity to study the impact of hydro- 
logical events at four different levels: original input 
data resolution, one-mile cell resolution, basin resolu- 
tion, and finally at the hydrology model "resolution." 

3. New models may be tested by entering "pseudo" data at any 
appropriate point in the system. 

4. The hydrology basin model interface allows the user to 
easily compare the results of different hydrology basin 
models. 

■As mentioned earlier the implementation of the AOIPS hydrology 
system for the demonstration v/as directed towards portions of the 
Hydrology Data Management System. The ability to process SMS data, 
LANDSAT data, and topographic data was developed to demonstrate 
those features of the system. Additionally, the ability to gene- 
rate the cell level data files as well as to enter, retrieve, 
display, and overlay information from those files was developed for 
the demonstration. The ability to process other data types includ- 
ing meteorological weather station data, historical ground truth 
data, stream gauge records and other point source data have not yet 
been developed. 

5.3.3 AOIPS Capability as Applied to the Needs of the Hydrology 

Application 

In the initial phases of the contract work, the usefulness of 
AOIPS to the hydrology application science appeared to be prin- 
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cipally as a system to process rav/ data into a form acceptable for 
use by existing hydrology models. For example, the AOIPS system 
could be used to transfer SMS data from its rav/ form (digital 
imagery) to a form accepted by NWSRFS (mean basin precipitation). 

As EarthSat scientists gained experience in using AOIPS hardware, 
it became apparent that this important function may not ultimately 
be the principal use of AOIPS by hydrologists. The interactive 

capability to display, overlay, and in general analyze digital 

* 

data, tied directly to a geocoded data base which contained all 
liydrologically-related parameters promises to be an extremely 
powerful tool for the research hydrologist to use in improving 
existing models and in developing new models. This marriage of 
display capabilities v/ith geocoded information data files contain- 
ing a variety of data types provides the researcher with the capa- 
bility to easily investigate spatial and temporal relationships 
between observed phenomena. The i;.i;eractive nature of the system 
will allow the -user to query the information files for specific 
types of events, "track" the events as they are processed by the 
AOIPS system, and then eventually by the large river forecast 
hydrology models. This type of application user "hands-on" experi- 
ence should result in valuable improvements in the understanding of 
hydrol ogy-rel ated phenomena . 
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5.4 AO I PS HYDROLOGY SOFTWARH DEMONSTRATION 

This section of the AO IPS Hydrology Demonstration is meant 
to compliment the actual demonstration performed on the AOIPS 
System. The figures shown here are selected from the actual 
displays to be generated on the screen of the Image 100. With 
the single excep.on of the multi spectral classification figure 
all of the figures v/ere generated on the DICOHED recorder. 

The multispectral classfication results figure was taken with 
a 35 mm camera. 


The Hydrology Data Management System vnll be demonstrated 
using all "real" data obtained for the Bear River Basin, 
The Bear River Basin, located in northeast Utah, southeast 
Idaho and western Wyoming was selected because it is a 
relatively small closed hydrological system. Figure 5-2 
shows the extent of the basin and the division into three 
sub-basin areas. There are 56 stream gauging stations 
located within the River Basin. 
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Figure 5-3 is a full frame LANDSAT synoptic view 
of the Bear River Basin. The terrain in the v/atershed 
is very rugged with mountain peaks as high as 9500 feet. 
The large body of water located in the southwest corner 
of the image is the Great Salt Lake. 



Figure 5-3 Full Frame LANDSAT of Bear River Basin 
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The first task in generating the Bear River Basin hydrology 
data bases was to digitize the three sub-basins within the 
watershed. The Bear River Basin map shown in Figure 5-2 was 
used to manually "polygonize" the sub-basins. The vertices 
of the sub-basin polygons were converted to latitude and 
longitude and input to the Hydrology Data Management Software. 
The Hydrology Data Management Software constructed the skeleton 
structure of the data bases from the polygon data. Each 
cell within the river basin was assigned to its appropriate 
sub-basin. Figure 5-4 shows a display taken from the data base 
which shows the assignment of cells to sub-basins. 
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Figure 5-4 


Bear River Watershed Sub-basins 
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After the initial data files have been generated, 

* 

remotely sensed data may begin to be processed 
and entered into the data bases. Figure 5-5 shows 
an example of LANDSAT imagery covering the Bear 
Lake region. The L/VNDSAT data shown in this 
figure has been aggregated up to an effective 
200 meter pixel resolution. 
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Figure 5-5 LANDSAT 200 Meter Sampled Image Around Bear Lake 




The LANDSAT data shown in Figure 5-5 was multi spectrally 
classified using the General Electric Image 100. The 
results of this classification are shown in Figure 6. 
Training sets were identified for 4 classes of data: 

1) water 

2) marsh 

3) forest 

*4) natural vegetation 

The results of the multi spectral classification were 
aggregated up to the 1 square mile cell level. The 
percentage of each cell assigned to each of the four 
classes was entered into the Archive Cell Data Base. 
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In addition to processing LANDSAT data, the Hydrology 
Data Management System allows for the use of SMS data 
to provide precipitation estimates. Figures 5-7 and 5-8 
show two typical SMS images over the Bear Lake area 
Using the Image 100 curser to outline cloud polygons 
the user may identify cloud extent, type and amount. 

The user is prompted to enter the cloud type and 
amount for- each polygon. The system then estimates 
precipitation produced by those clouds. The preci- 
pitation estimates are then entered into the daily 
all data base. 
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The final type of data processing to be shown at this 

demonstration is digitized topographic data. Figure 5-9 

shows an example of raw topographic data. The gray map 

display was generated by stretching the topographic 

elevation range of 0 to 10,000 feet over a gray value 

interval of 0 to 255. Each step in gray value represents 

a rise of approximately 39 feet in elevation. The lighter 

the gray shade on Figure 9, the higher the elevation. This 
% 

topographic data may be entered into the Archive Cell Data 
Base in the same way that the LANDSAT data v/as entered. 
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Figure 5-9 Raw Image Display of Topograpfric Data 
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The final display shov/n in Figure 5-10 is a 3 dimensional 
perspective plot generated from the digitized topographic 
data. This type of plot can be interactively produced 
for any area for which topographic data is available. 

The 3 dimensional perspective plot allows the user to 
easily visualize the topography of the area to be 
analyzed. 
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5.5 CONCLUSIONS AND RECOMMENDATIONS 


5.5.1 Conclusions 

Previous experience by EarthSat personnel in a variety of 
application areas has demonstrated the utility of storing implemen- 
tations data in a geocoded reference system. Work’ performed under 
this contract has shown the increased advantages of directly tying 
the geocoded data base to an interactive display capability such as 
that available on AO I PS. 

In specific applications of hydrology it should be pointed out 
that the existing hydrology models consider as their "smallest unit 
of information" the watershed basin or sub-basin area. Sub-basin 
areas may in fact cover a large geographic area displaying a vari- 
ety of terrain, vegetation covered patterns, soil types, etc. The 
natural resolution of various remotely sensed data is frequently 
much smaller than the sub-basin level. It is therefore possible to 
study a watershed area at a level much smaller than that currently 
used by the principal hydrological model. This capability to study 
a basin or a watershed on a variety of spatial levels promises to 
be a great aid to the application scientists. 

5.5.2 Recommendations 

As a result of the work performed under contract NAS5-22894 
Earth Satellite Corporation recommends: 

1. The implementation of the geocoded Hydrology Applications 
Data Management System be completed with emphasis directed 
towards the river forecast problem. 


2. Potential hydrology application users be strongly encour- 
aged to use the existing portions of the system to gain 
hands-on experience with their own hydrology problems. 

Additionally, Earth Satellite scientists believe that v/hile 

# 

the specific details of this system design are currently directed 
toward the hydrology applications area the general design concept 
used here is applicable, and in fact directly transferable, to many 
other application areas. The geocoded data base is developed for 
the hydrology applications which are structurally similar to the 
agrometerological data files used by the A6MET yield modeling 
systems developed at EarthSat. The interactive nature of the 
hydrology systems is certainly applicable to many other application 
areas including agronomy, forestry, and range land management to 
name only a few. EarthSat therefore recommends a consideration be 
given to broadening the scope of the hydrology activities to include 
other discipline areas. 
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APPENDIX A 


SOFTWARE DOCUHENTATIOM 


1.0 OVERVIE W 

Appendix A contains documentation for all software items delivered 
under this contract. Source, objects, and task modules are all contained 
on the EarthSat RP04P disk pack, LABEL=ESC, under UIC [350,35]. The 
software items are divided into three categories: 

1. General purpose subroutines, 

2. Pre-existing software included on the deliverable items list 
of the contract, 

3. Data management software developed specifically for the con- 
tract. 

Documentation of categories two and three assumes familiarity with the 
subroutines included in category one. 

Most of the software items consist of a main program which drives 
one or more subroutines. Each is documented in a separate module, but 
all module common to a task are grouped together and preceded by a func- 
tional description of that task. 

Documentation for each modular includes the follov/ing: 

1. Functional description 

2. Description of argument list (if applicable) 

3. Description of common areas 

4. Description of variables 

5. Flow chart 

Unless otherwise specified all variables are INTEGER*2. Sort 
listings are not included in this appendix but are included in a sep- 
arately bound file. 


2.0 GENERAL PURPOSE SUBROUTINES 


2.1 OPEN 

Subroutine OPEN opens a file on disk, tape or refresh memory. It 
accepts an input/output flag and a logical unit number, and checks to 
see if the LUN is already open. It then prompts the operator for a 
device type and calls the appropriate subroutine (OPENMT, OPENRD, OPENIC) 
to open the file. 

2.1.1 Argument List 


a. 

10- 

input/output flag, equals 0 if file is for input. 


equals 1 if file is for output. 

b. 

LUN-Logical Unit Number. 

?,1.2 

COMMON Areas 

a, 

DCB 



1. 

LUNTAB (10) - Stores device type and I/O flag for up 



to 10 LUNS. 


2. 

FUNCT (10) - Stores QIO function for magnetic tape 



files. 


3. 

RECORD (10) - Stores current record number for 



refresh files. 


4. 

START (10) - Contains starting line number for 



refresh files. 

2,1,3 

Variables 


a. TYPE (3) - Stores device type codes (T,D,R) in ASCII. 

b. DEVICE - Stores desired device type in ASCII. 
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2.1.4 User's Guide 


PROMPT " RESPONSE 

OPENING LUN (1-10) FOR ( INPUT/ OUTPUT ) 


(T) APE, (D) ISK, OR (R) EFRESH? T, D, or R 












H.2 OPEUMT 


Subroutine OPENMT is called to open a magnetic tape file. First, 
it constructs a table entry to describe the file. This entry is of the 
form ll)g where I = 0 if the file is for input and I = 1* if the file is 
for output. Next, the user is prompted for the following information; 

K File number; 

2. Tape density; 

3. Maximum parity errors; 

4. Physical number of the tape drive. 

ASNLUN is then called to assign the LUN to the specified tape drive 
and the device is attached to the task to restrict access to the tape 
drive. QIO is called v/ith a function of lOSMO to simultaneously set the 
tape characteristics and check for load point positioning. If the tape 
is not at load point, the characteristics will not be set and a fatal 
hardware error will result. At this point the user has the option of 
continuing or exiting. If he chooses to continue, the characteristics 
are set using the QIO function lOSTC which will not check for load point 
positioning. Finally, the tape is positioned to the desired file using 
the QIO function lOSPF. 

2.2.1 Argument List 

a. 10 - Equals 0 for input file, 1 for output file 

b. LUN - Logical Unit Number 
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2.2.2 Common Areas 


a. DCB “ see 2.1.2 

b. ST AT - 

1. 1ST AT (2) - I/O Status block 

2. IPRM (6) - QIO parameter list 

3. ISW - Directive status word 

c. 10 - 

1. MAXPAR (10) ~ Maximum parity errors allowed 

2.2.3 Variables 

a. I DEV - Stores ASCII, device name "MM" 

b. lOSMO " QIO function, set characteristics and verify load 
point positioning 

c. lOSTC - QIO function, set characteristics 

d. lOATT - QIO function, attach device 

e. lOSPF - QIO function, skip file 

f. NFILE - File number 

g. TDEN - Tape characteristics, octal mask . 

h. DEN - Tape density, 800 or 1,600 

i. DNUM - Device number 

j. FLAG “ Flag for lOSMO, equals 1 if LUN not at load point 

2.2.4 User's Guide 

PROM ' JT RESPONSE 

FILE NUMBER = 


TAPE DENSITY = 


positive integer 
800 or 1,600 


PROMPT 


RESPONSE 


MAXIMUM PARITY ERRORS = positive integer or carriage 

return for default of ten 
TAPE DRIVE NUf-ISER = 0 or 1 











2.3 OPENRD 


Subroutine OPENRD is called by OPEN to open a file on disk storage. 
First a table entry is constructed in the form 101) where I = 0 for an 

O 

input file, 1 for output file. The user is prompted for a file name 
which must be prefaced by the device name if the file does not reside on 
SY:. The specified LUN is assigned to the file and control is returned 
to open. 

2.3.1 Argument List 

a. 10 “ Equals 0 for input, 1 for output 

b. LUN - Logical Unit Number 

2.3.2 Common' Areas 

a. DCB - see 2.1.2 

b, STAT - see 2.2.2 


2.3.3 Variables 

a. FILE (18) - Logical * 1 

2.3.4 User's Guide 

PROMPT 

DISK FILE NAME? > 

RECORD LENGTH (BYTES?) > 
NUMBER OF RECORDS? > 


stores ASCII file name 
RESPON SE 

18-character file name, including 
device name if other than SY; 
even positive integer 
to allocate disk storage, enter 
integer number of records. For 
no initial allocation, press 
carriage return 


2.4 OPENIC 


Subroutine {3PENIC is called by OPEN to open a refresh memory file 
and allow the user to specify a separate LUN for each channel. These 
are dummy LUN's, as only one may be assigned to IC: and this is done 
at task build. Each dummy LUN points to the real LUN which along with 
the channel number defines the location of the file. 

OPENIC constructs a table entry into LUNTAB in the form lOOOCI)^ 
where C = channel number, 1=0 for input and 1 for output. The user is 
prompted for starting line number to define the absolute position of the 
file. Any subsequent REREAD commands will position the file to this 
line number. Finally, the file pointer is set equal to the start line 
to position the file at its beginning. 

2.4.1 Argument List 

a. 10 - 0 for input, 1 for output 

b. LUN - Logical Unit Number 

2.4.2 Comon Areas 

a. DCB - see 2.1.2 

2.4.3 Variables 

a. CHAN - Channel number 

2.4.4 User's Guide 

PROMPT RESPONSE 

CHANNEL NUMBER? > 1-5 

STARTING LINE NUMBER? 0-511 or carriage return for 

(DEFAULT EQUALS 70) > default 

















2.5 reader 

Subroutine READER is called to read a block of data from the 
specified file. The file type is extracted from LUNTAB vdiich determines 
how the record is read. For a tape files s QIO directive (lORLB) is 
issued; for refresh memory, TRV is called and a record pointer is in- 
cremented. Disk I/O is accomplished through a call to FVREAD. 

2.5.1 Argument List 

a. LUN - Logical Unit Number 

b. BUFFER - I/O buffer 

c. BUFLEN - Buffer length in words 

2.5.2 Common Areas 

a. DCB - see 2.1.2 

b. STAT - see 2.2.2 

2.5*3 Variables 

a. lORLB - QIO function, read logical block 








2.6 IjRITER 

Subroutine WRITER is called to v^rite a block of data to a specified 
file. The file type is extracted from LUNTAB v^hich determines how the 
record is written. For a tape file a QIO directive (lOVJLB) is issued; 
for refresh memory IWV is called and the record pointer is incrementedf 
and disk I/O is accomplished through a call to FVWRIT. 

2.6.1 Argument List 

a. UUN - Logical Unit Number 

b. BUFFER - I/O buffer 

c. BUFLEfi - Buffer length (words) 

2.6.2 Common Areas 

a. DCB - see 2.1.2 

b. STAT ~ see 2.2.2 

2.6.3 Variables 

a. lOWLB - QIO function, write logical block 




2.7 REREAD 


Subroutine REREAD positions the specified file to a starting point. 
For a tape file, the QIO directive lOSPF is issued vjith a parameter of -1 
to skip to the last EOF mark encountered. Positioning that may refresh 
file is accomplished by resetting the record pointer to the starting 
line number. Positioning of a disk file is accomplished through a call 
to FVDSET with an argument of 1. 

« 

2.7.1 Argument List 

a. LUN - Logical Unit Number 

2.7.2 Common Areas 

a. DCB - see 2-1.2 

b. STAT - see 2.2.2 

2.7.3 Variables 

a. lOSPF - QIO function, skip EOF mark 












2.8 RWWD 


Subroutine RWND is essentially the same as REREAD for refresh, 
disk, or single file magnetic tape. Hov/ever, for a multi-file magnetic 
tape RWND positions to the load point rather than the beginning of the 
current file, 

2.8.1 Argument List 

a. LUN - Logical Unit Number 

6 

2.8.2 Common Areas 

a. DGB - see 2. 1,2 

b. STAT - see 2,2.2 

2.8.3 Variables 

a. IQRWD - QIO function, rewind tape 
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2.9 EOF 


Subroutine EOF checks to see if the specified LUN has been opened 
for output and if so writes an end-of-file mark. For a magnetic tape, 
two marks are written to indicate EOV. This is accomplished by issuing 
two successive QIO requests (lOEOF). For a disk file or referesh file, 
control is simply returned to the calling routine. 

2.9.1 Argument List 

a. LUN - Logical Unit Number 

2.9.2 Common Areas 

a. DCB - see 2.1.2 

b. STAT - see 2.2.2 
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2.10 WAIT 


Subroutine WAIT is called after an asynchronous I/O request to 
wait for the event flag associated with specified LUK. For a refresh 
file ICVIAIT, a system subroutine which waits for the event flag asso- 
ciated with IC;, is called. For magnetic tape WAITFR a system sub- 
routine which waits for a specified event flag is called with an 
argument of 10. The LUN is used to point into FUNCT which contains 
codes describing which I/O function was last performed on each unit. 
This information is then passed to the QIO error handling routine, BDSW 
and BDSTAT. A disk file is synchronized through a call to FVWAIT. 

2.10.1 Argument List 

a. LUN, Logical Unit Number 

b. FLAG - EOF flag equals on encountering end-of-file 

2.10.2 Common Areas 

a. DCB - see 2.1.2 

b. STAT - see 2.2.2 


- l^RODUCIBILITY OF im 
mWNL PAOB IS POOR 
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2.11 SET 


Subroutine SET is used to set an event flag associated vnth a 
specified LUN. This is accomplished through a call to system subroutine 
SETEF. For magnetic tape file SETEF is called vdth an argument of 10; 
for refresh memory SET is called with an argument of 23, and for a disk 
file SETEF is called with an argument which is one greater than the 
logical unit number, 

* ■ 

2.11.1 Argument List 

a. LUN - Logical Unit Number 

2.11.2 Common Areas 

a. DCB - see 2.1.2 

b. STAT - see 2.2.2 
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2.12 SKIP 


Subroutine SKIP is called to space forv;ard or backward a specified 
number of records. For a refresh file the number of records to be 
skipped is added to the record pointer. For a magnetic tape the number 
of records to be skipped is entered in the first word of ’the parameter 
list and a QIO request (lOSPB) is issued. After waiting for completion 
of request the QIO error checking routines are called. Disk file posi- 
tioning is accomplished by converting the number of records to virtual 
block number and passing the block number to FVDSET. 

2.12.1 Argument List 

a. LUN - Logical Unit Number 

b. NSKIP - Number of records to be skipped 

2.12.2 Common Areas 

a. OCB - see 2.1.2 

b. STAT - see 2, 2.2 

2. 12. 3 Vari ables 

a. lOSPB - QIO Function, SKIP block “ ‘ 

b. VBN - Virtual Block Number 


Subroutine UNPiC is called by reader and writer for refresiv files 
only. This module extracts the channel number from LUNTAB by shifting 
LUNTAB (LUN) three bits to the right, and then performing a logical OR 
with a mask which has only the three lower bits turned on, 

2.13.1 Argument List 

a. WORD •* Logical Unit Number table entry 










2.14 BDSW 


Subroutine BDSW is called to check for errors in the directive 
status word (DSW). The DSW indicates the success or failure of a queue 
I/O request only, A "1" in the directive status word indicates that the 
request was successfully queued. It contains no information about the 
status of the I/O function itself. 

If the DSW equals one» BDSW returns with no action taken. If the 
DSW is negative* an error message is typed on the terminal and control 
is transferred to the executive through the system subroutine EXIT. 

2.14.1 Argument List 

a. EVENT - I/O function code 

b. LUN - Logical Unit Number 

2.14.2 Common Areas 

a. 10 see 2.2.2 

b. STAT see 2.2.2 

2.14.3 Variables 

a. FCODE (10*3) - Used to store the ASCII characters for the 
10 possible QIO functions 
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2.15 BDSTAT 

Subroutine BDSTAT is called after a successful I/O queue to check 
the I/O status block. If the I/O request was executed normally, ISTAT{1) 
equals one. BDSTAT first checks for a status word of one; if it is 
found control returns to the calling program. Next it checks for an 
end-of-volume error, ("365) which if found is ignored. If an EOV error 
is not detected the function code is checked. If any function other 
than lOSMO (set tape characteristics and verify load point) or lORLB 
(read logical block) is found, an error message is typed on the terminal 
and control is transferred to the executive through the system sub- 
routine EXIT. 

If the function is lOSMO, BDSTAT checks for a fatal hardware error, 
(lEFHE), which is the error returned if the tape is not at load point. 

If lEFHE is detected the user Is notified and asked if he desires to 
continue or terminate. At this point the user may manually position the 
tape or take other appropriate action. If he desires to continue con- 
trol is returned to OPENHT with a FLAG equal to minus one. This in- 
dicates to OPENMT that it should issue an lOSTG request to set the 
characteristics without verifying load point positioning. If an error 
other than lEFHE is detected the task is terminated and an error message 
is typed on the terminal. 

If the device function is lORLB, BDSTAT checks first for the error 
lEDAO which indicates that the record length exceeded buffer area. If 
found this error is ignored and control is returned to the calling 
program. Next the status block is checked for lEEOF which indicates 
end-of-file. If this is found, FLAG is set to minus one and control is 
returned to the calling program. If lEEOF is not detected the status 


word is checkod for lEVER v/hich indicates a parity error. If found the 
parity error count is incremented and compared v/ith the maximum al- 
lowable number. If the maximum number of parity errors is exceeded an 
error message is typed and the task exits. Otherwise control returns to 
the calling routine. Any other error message resulting 'from an lORLB is 
considered unconditionally fatal and results in abnormal termination of 
the task with an appropriate error message. 

E.15.1 Arguments 

a. EVENT - I/O function code used to point into FCODE 

b. LUN - Logical Unit Number 

c. FLAG “ Equals minus one to indicate an error which should 
be handled by calling routine 

2.15.2 Cornmon Areas 

a. 10 - see 2.2.2 

b. STAT - see 2.2.2 

2.15.3 Variables 

a. FCODE (10,3) - stores ASCII characters for the 10 QIO 
function codes 

b. NPAR (10) - contains the number of parity errors en- 
countered on LUN's 1-10 

c. MASK - logical mask, high order byte off, low order byte 
on 

d. lEFHE - error code, fatal hardware error 
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e. lEDAO - error code, record length exceeds buffer 

f. lEEOF - error code, end-of-flle 

g. lEVER - error code, parity error 
















2.16 GTWND 


Subroutine GTWND is an interface routine which prompts the user for 
the window coordinates of an input image. 


2.16.1 Argument List 

a. FROW - first row 

b. NROWS - number of rows 

c. FCOL - first column 

d. NCOLS - number of columns 

2.16.2 Common Areas 
None 


2.16.3 Vari ab1 es 
None 

2.16.4 User's Guide 


PROMPT 

START ROW NUMBER? > 
START COLUMN NUMBER? > 
NUMBER OF ROWS? > 
NUMBER OF COLUMNS? > 
CONTINUE? > 


RESPONSE 
Integer 
Odd Integer 
Integer 
Even Integer 
Y or N 


3.0 APPLICATIOHS SOFTWARE 


3.1 GRAY 

GRAY is a multi-purpose task which allov/s the user to modify 
the gray scale of an image in a number of ways including: 

1. Linear transformation 

2. User defined transformation i - 

3. Histogram equalization 

In addition to its image enhancement capabilities a GRAY can 
also be used for image contouring or density slicing. 

Separate versions of GRAY are available for the 11/70 and the 
Image 100. The 11/70 version is described in the follovifing sections 
and the Image 100 modifications are outlined in Section 3.1.10. 

3.1.1 MAIN 

The function of MAIN is to prompt for the desired 
option, check to see that processing is proceeding in the 
correct sequence, and call the required sub-routines to per- 
form the processing. Five options are recognized: 

1. SCAN - scan the input image 

2. FUNCTION - define a gray scale transform 

3. PICTURE - produce a transformed image 

4. OVERRIDE - override processing order 

5. STOP 

The correct processing order for most applications is 
SCAN, FUNCTION, PICTURE, STOP. If it is desirable to omit the 
SCAN or FUNCTION steps, the OVERRIDE option must be used. 
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3. 1.1.1 Coininon Areas 


A, 

MAXMIN 


1. 

MINORG - original minimum gray value 


2. 

MAXORG - original maximum gray value 


3. 

HINFNL - final minimum gray value 


4. 

MAXFNL - final maximum gray value 

B. 

WNDW 



1. 

IRB » first row 


2. 

a' . . 

IRE - last row 


3. 

ICB - first column 


4. 

ICE - last column 


5. 

INC - scan increment 

C. 

SCALE 


1. 

ISCL(255) - gray scale transfor- 



mation vector 

D. 

LUN 



1 . 

TIN “ input image LUN 


2. 

TOUT “ output image LUN 


3. 

NIN - control terminal LUN 


4. 

NOUT - line printer LUN 


3. 1.1.2 Variables 

A. KSCAN - scan flag 

B. KFUNC- function flag 

3.1.2 I NIT 

Sub-routine INIT is called by MAIN to initialize the 
variables and arrays in common blocks MAXMIN, SCALE, LUN, and 
VECT. . 
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3. 1,2.1 Argument List - None 


3. 1.2. 2 Cornmon Areas 

A. MAXMIM - see 3.1.1.1 

B. SCALE - see 3.1.1 .1 

C. LUN - see 3.1.1.1 

D. VECT 

1. INTHIS(256) - input histogram 

2. FNLH1S(256) - transformed histogram 

3.1.3 I SCAN 

Sub-routine ISCAN calls GTWND to get the window coordi- 
nates, prompts the user for the scan increment and then calls 
SCAN (see 3.2,2) to obtain a histogram of the input image. 
Before returning, ISCAN calls HHIST (see ) to produce a 
display of the histogram on the line printer. 

3.1 >3.1 Argument List - None 

3. 1.3. 2 Common Areas 

A. - WNDW - see 3.1. 1.1 

B. SCALE - see 3. 1.1.1 

C. LUN - see 3. 1.1.1 

D. VECT - see 3. 1.2. 2 

3.1 .3.3 Variables 

■ A, INC - scan increment 

B, NROWS - number of rov;s of input 

C. NCOLS - number of columns of input 
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3.1.4 GRYSCL 


Sub-routine fiRYSCL allows the user to define the desired 
gray scale transformation, using one of five available options. 

Option 1 defines an identity transformation where the 
output image is identical to the input image. 

Option 2 allows the user to manually specify the desired 
transformation through the control terminal. This option is 
used for density slicing or contouring. 

Option 3 accepts an initial and a final gray value 
range, then defines a linear transformation to stretch or 
compress the initial range to the final range. 

Option 4 is a duirany option provided for future expansion 
of the program. 

Option 5 allows the user to specify a spread factor in 
the form of percent of final range. It then calculates the 
mean and standard deviations above and below the mean of the 
original histogram. A linear transformation is then defined 
such that the gray values within one standard deviation of the 
mean are mapped into the range specified by the spread factor. 
This option requires an initial scan. 

Option 6, known as histogram equalization, attempts to 
produce a flat histogram by aggregating the gray values in 
sparsely populated regions of the histogram while spreading 
densely populated gray values. This option requires an initial 
scan. 


3.1. 4.1 Argument List 

A. NBR - option number 
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3. 1.4. 2 Common Areas 


A. SCALE - see 3.1.1 .1 

B. VECT - see 3.1.2.2 

C. MAXMIN- see 3.1,1.! 


3. 1.4. 3 Variables 

A. ISTD - spread factor for Option 5 

B. IMEAN - original histogram mean 

C. SLOW - REAL*4, standard deviation below 
mean 

0. SUPP - REAL*4, standard deviation above 
mean 

E. MEANF - final mean of histogram 

3.1.5 SLICER 

Subr-mttine SLICER is called by GRYSCL when Option 2 is 
specified. It allows the user to enter the desired gray scale 
transformation by typing a gray value follov^fed by a repetition 
factor. This reduces the possibility of having to type in 256 
separate gray values. 

3. 1.5.1 Argument List - None 

3. 1.5. 2 Common Areas 

A. SCALE see 3. 1.1.1 

3.1.6 HISEQL 

Sub-routine HISEQL is called by GRYSCL when Option 6 is 
specified. From the input histogram it calculates the average 
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number of pixels per gray value, then aggregates sparse 
population values to bring them up to the average. It also 
spreads the densely populated values so that a gray value with 
a population of N times the average will be followed by N-1 
unpopulated values. 

3. 1.6.1 Argument List 

A. MINFNL - minimum final gray value 

B. MAXFNL - maximum final gray value 

C. INTHI5(256) - input histogram 

D. ISCL(256) - gray scale transformation 
vector 

3. 1.6. 2 eommon Areas - None 

3.1. 6. 3 Variables 

A. NGV - number of gray values in output 
range 

B. ISUM - histogram population 

C. GV - REALH, transformed gray value 

3.1.7 PICT 

Sub-routine PICT is called by MAIN v;hen the PICTURE 
option is specified. It calls GTWND to get the window coordi- 
nates, then calls LITTON which generates the output image. 

3. 1.7.1 Argument List - None 

3.1 .7.2 Common Areas 

A. WNDW - see 3.1.1.1 


3-. 1.7. 3 Variables 

A. NROWS - number of rows to be processed 

B. NCOLS “ number of columns to be processed 

3.1.8 LinON 

Sub-routine LITTON is called by PICT. It reads the 
input image and applies the gray scale transformation to 
produce the output image. 

3. 1.8.1 Argument List - None 

3. 1.8. 2 Common Areas 

A. WNDW - see 3.1.1.1 

B. SCALE - see 3.1. 1.1 

C. LUN - see 3.1.1.1 

3.1.9 User’s Guide 

GRAY is initiated by the MCR command RUN GRAY$. in 
addition, to the information required by OPEN .{see 2.1.4) and 
6TWND (see 2.16,4)* the user will be prompted for the following 
information. 

PROMPT 
OPTION = 

For option = SCAN 

SCAN INCREMENT?> 

For option = FUNCTION 
GRAYSCALE 0PTI0N#?> 
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RESPONSE 

SCAN, FUNCTION, PICTURE, 
OVERRIDE, or STOP 


Positive integer 


1, 2, 3, 5, or 6 


For option #2 
?> 

For option #3 

TYPE IN ORIGINAL MINIMUM AND 
MAXIMUM GRAY VALUES > 

TYPE IN FINAL MINIMUM 
AND MAXIMUM GRAY VALUES > 

For option #5 
SPREAD FACTOR? > 


Gray value (0-255)» Repetition 
factor { 1-256) 


Integer (0-255) , Integer 
(0-255) 


Integer (0-255), Integer 
(0-255) 


Integer (1-100) or carriage 
return for default of 66 % 


3.1. TO IMAGE-100 Modifications 

For use on the IMAGE-100 System several modifications 
were made in GRAY. In ISCAN the scanning window is read from 
the cursor and up to four channels may be scanned at once. To 
be prompt 


SCAN CHANNEL (I:!)? > 

the user should respond with a carriage return if scanning is 
desired and any noii-blank character if it is not. If the 
override option is used the user should respond similarily to 
the 


ADJUST CHANNEL (1-4)? > 


request. Modifications were also made to HISEQL in order to 
achieve the optimum results on the Image-100. 
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To histogram equalize a three-band, color, LANDSAT 
composite, the user should first adjust the color mix to his 
personal preference. Next he should run GRAY, scanning the 
three channels with image data. Next the FUNCTION OPTION 
should be selected and in response to the prompt 

STEP WEDGE ON CHANNEL? > 

the one unused channel (1-4) should be entered. After option 
six is selected, GRAY will ask the user to divide the output 
gray scale into three regions with the following prompts 

MINIMUM OUTPUT VALUE? > 

FIRST CUTOFF? > 

SECOND CUTOFF? > 

MAXIMUM OUTPUT VALUE? > 

These values may be entered either by typing in a value 
or by placing the cursor of the desired point of the step 
wedge and pressing the carriage return. The first cutoff 
should be in the region where the transition from black to 
gray begins. The second cutoff should be in the region where 
no more change in brightness can be detected. Good results 
can be achieved by setting the maximum and minimum values at 0 
and 150 respectively. Finally GRAY will prompt v/ith 

PERCENT BEFORE FIRST CUTOFF? > 

PERCENT AFTER SECOND CUTOFF? > 
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Good results can be achieved by responding with ten to 
both prompts but experimentation is encouraged. 

GRAY vdll proceed to histogram equalize the first M 
percent of the input histogram to the range founded by the 
minimum value and the first cutoff, the last N percent to the 
range between the second cutoff and the maximum value, and the 
remainder of the input histogram to the range between the tv;o 
cutoffs. N and M are the numbers which are typed in response 
to the percent before first cutoff and percent after second 
cutoff prompt respectively. The effect is to equalize most of 
the histogram in the area of maximum transition on the screen 
of the Image-lOO, 

The PICTURE OPTION will then apply transformation to 
all three channels. Output is to the original channel, therefore 
the original data is lost. 
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GET SPREAD 
RANGE 




CALCULATE | 
HISTOGRAM MEAN 

and standard 

DEVIATION 



SPREAD GRAY 
values w^ithin 

ONE STANDARD 


DEVIATION 
OF MEAN OVER 
SPREAD RANGE 






























3.2 EHLR6 


This task produces a times tv;o enlargement of a digital image. The 
maximum input v;indow of 258 x 258 pixels will yield an output image of 
512 X 512. Rather than using a simple pixel repeat* ENLRG incorporates 
a sampling technique to generate four pixels for each input pixel. The 
algorithm utilizes the four nearest neighbors as follows: 

$N1 G3 + (G1 + G2 - G4 - G5)/8 

6N2 - 63 + (61 + 64 - G2 - G5)/8 

GN3 = 63 + (G2 + G5 - G1 - G4)/8 

GM4 = G3 + (G4 + 65 - 61 - 62)/8 


Prior to generating the four new pixels the original gray values 
are stretched by the maximum allowable amount to minimize truncation in 
the calculations. 

3 . 2.1 mm 

The function of MAIN is to perform housekeeping tasks such 
as opening files and to provide a driver for the necessary sub- 
routines. The image is scanned, a gray scale transformation is 
defined, and finally the image is enlarged. 


3. 2.1.1 CoiTOtion Areas 


a. LUN 

1. LUNI “ Input Image Logical Unit Number 

2. LUNO - Output Image Logical Unit Number 

3. NIN - Control Terminal Logical Unit 

Number 

4. NOUT - Line printer Logical Unit Number 

b. WINDIN 

1. NROW - *^irst row of input image 

2. NROWS “ Number of rows input 

3. NCOL - First column of input image 

4. NCOLS - Number of col urns of input image 
' c. WINDOT 

1. MROW - First row of output image 

2. HROWS - Number of rows of output image 

3. MCOL ** First column of output image 

4. HCOLS - Number of columns of output image 
. d. GRYSCL 

1. Scale (256) - gray scale transformation 
vector 

3.2. 1.2 Variables 

a. HIST (256) - Histogram of scanned image 

b. INC - Scan increment 

c. NSKIP “ Number of records to skip to 
position input window 
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3.2.2 SCAN 


Subroutine SCAN accepts a Logical Unit Number, window 
coordinates, and a scan increment (N), and returns an accumulated 
histogram of every Nth pixel in every Nth row. SCAN does not 
reposition the file to its starting point. 

3.2.2. 1 Argument List 



a. 

NROWS - Number of rows to be scanned 


b. 

• 

NCOLS - Number of columns to be scanned 


c. 

NROW - Starting row number 


d. 

NCOL - Starting column number 


e. 

HIST - (256) - Histogram counters 

3. 2.2.2 

Common Areas 


a. 

LUN - See 3.2.1.1 

3.2,2.3 

Variables 


a. 

PIXEL - extracted gray value 


3.2.3 HISTR 

Subroutine HI SIR accepts an image histogram and returns a 
gray scale transformation vector. First the minimum and maximum 
histogram limits are determined. The minimum is defined as that 
gray value for which there is a population of 25 which is either 
less than or equal to the gray value. The maximum is similarly 
defined so as to reduce the effect of high and low-level noise on 
the stretching process. Using these limits, a linear transfor- 
mation is defined to stretch the maximum-minimum range the largest 
integer amount possible while remaining within the 0-255 limits. 
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3. 2. 3.1 Argument List 

a. HIST (256) - Accumulated histogram 

b, SCALE (256) - Gray scale transformation vector 

3. 2. 3. 2 Common Areas 

None 

3. 2. 3. 3 Variables 

a. ICUT “ minimum and maximum cutoff population 

b. MIN “ minimum histogram value 

c. MAX - maximum histogram »alue 

d. MR - histogram range 

e. HA - maximum stretch value 

f. NMIN - new minimum value 

g. UMAX - new maximum value 

3.2.4 EXPAND 

Subroutine EXPAND reads the input image and produces an 
enlarged output image. It starts by initializing buffer pointers 
and reading the first few records of the image. After each record is 
written it is expanded to one pixel per full word and the trans- 
formation defined in HISTR is applied. A loop is entered in which 
the buffer point which indicates the order in which the buffers 
were filled are rotated, a record is read, expanded into the third 
buffer, and the enlargement is performed. Finally two records of 
the enlarged image are vjritten and the loop restarts until the 
entire image has been enlarged. 


3. 2. 4.1 Argument List 


None 

3. 2. 4. 2 Common Areas 

a. WINDXN - See 3. 2.1.1 

b. LIM 

1, LXH1 - first v/ord in input window 

2. LIME - last vrord in input window 

c. LUN - see 3. 2. 1.1 * 

d. WIMDOT - see 3.2.1. 1 

e. DBUF 

1. BUFFI (256) - input buffer and output 
buffer number 1 

• 2. BUFF2 (256) - output buffer number 2 

f. WBUF 

1. LINE (258,3) - three buffers for expanded 
date 

3. 2.4. 3 Variables 

a. LI - buffer pointer number 1 

. b, L2 - buffer pointer number 2 

c. L3 - buffer pointer number 3 

d. BLEN2 - input buffer length 

e. BUFLU2 - output buffer length 

f. FLAG - end-of-file indicator 

g. INDEX 7- output buffer position pointer 

h. G1 - input gray value number 1 

i. G2 - input gray value number 2 
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j. G3 - Input gray value number 3 

k. G4 - input gray value number 4 

l. G5 •* Input gray value number 5 


3.2.5 XPDBYT * 

Subroutine XPDBYT accepts a buffer of input data in the form 
of one pixel per byte, a transformation vector, and column limits. 
It returns a buffer of transformed gray values in the form of one 
pixel per word. 

3. 2. 5.1 Argument List 

a. NUM - Buffer number to receive expanded data 

3. 2. 5. 2 Common Areas 

a. LIM - see 3.2.4.2 

b. GRYSCL - sea 3.2.1.1 

c. DBUF - see 3.2. 4.2 

d. WBUF - see 3.2.4.2 

3.2.5.3 Variables 

a. HBYT - high order pixel 

b. tBYT ~ low order pixel 

3.2.6 User*$ Guide 

ENLRG is initiated by the HCR command RUN ENLRG$. In ad- 
dition to the information required by OPEN (see 2,1.4), the user 
will be prompted for the following: 
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PROMPT 


RESPONSE 


START ROW = 

NUMBER OF ROWS = 
START COLUMN = 
NUMBER OF COLUMNS = 


Integer number 
Integer number 
Odd integer number 
Even integer number 



ENLARGE 



^ CALL OPEN ^ 


^ CALL SCAN ^ 


^ CALLHISTR ^ 


^ CALLRgRgAD^ 


^ CALL SKIP ^ 




^ CAU-Ct^E ^ 


(. ) 


A-59 










HISTR 























3.3 REDUCE 


REDUCE produces a times two reduction of a digital image by re- 
placing successive 2x2 pixel areas with their average gray value. 
Before reduction takes place the image is scanned to determine the gray 
value range and a linear transformation is defined to provide the 
maximum amount of stretch without exceeding the gray value limit of 255. 
The 2x2 averages are then calculated using the transform gray values 

thereby reducing integer truncation to a minimum. 

•• 

3.3.1 MAIN 

The function of MAIN is to perform housekeeping functions 
such as opening files, and to provide a driver for the necessary 
subroutines. The image is scanned, a gray scale transformation is 
‘ defined, and finally the image is reduced. 


3. 3. 1.1 Common Areas 

a. WINDIN 

1, NROW - First row input image 

2, NROWS - Number of rows of input image 

3. NCOL - First column of input image 

4. NCOLS - Number of columns of input image 

b. WINDOT 

1. MROW - First row of output image 

2. MROWS - Number of rows of output image 

3. MCOL - First column of output image 

4. MCOLS - Number of columns of output image 
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c. LUN 


1. LUNI “ Input image Logical Unit Number 

2 . LUNO - Output image Logical Unit Humber 

3. NIN - Logical Unit Number for control 
terminal 

4. NOUT - Logical Unit Number for line printer 
d. GRYSCL 

1. SCALE (256) - gray scale transformation 
vector 


3. 3. 1.2 Variables 

a. HIST (256) - Histogram of scanned image 

b. INC - scan increment 

c. NSKIP - number of rows to be skipped 


3.3.2 SCAN 

See 3.2.2 


3,3.3 HISTR 

See 3,2.3 


■3.3.4 REDUCE 



Subroutine REDUCE does the actual image reduction, gener- 
ating one, half-length line for each two full-length lines of 
input. After each input line is read it is immediately expanded to 
one pixel per word in XPDBYT. The reduction process consists of an 
arithmetic average over a 2 x 2 pixel area rather than a simple 
sampling technique. 
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3. 3. 4. 2 Argument List 
None 

3. 3.4. 3 Common Areas 

a. LUN - see 3. 3. 1.1 

b. LIH 

1. LI Ml - first word of input buffer 

2. LIM2 - last word of input buffer 

c. WINDIN - see 3.3.1, 1 

d. WINDOT - see 3.3.1.1 

3.3.4.4 Variables 

a. BUFFI (256) - first input buffer 

b. BUFF2 (256) - second input buffer also used 
as output buffer 

c. LINE (2,1024) - buffer area for expanded lines 

d. BLEN - input buffer length 

. e. BLEN2 - output buffer length (words) 

f. FLAG - end-of-file flag 

g. GNl - contains first of pair of generated 
pixels 

h. GN2 - contains second of pair of generated 
pixels 

3.3.5 XPDBYT 

See 3.2.5 
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3.3.6 User's Guide 

REDUCE is initiated by the HCR command RUN REDUCES 
addition to the information required by OPEN {see 2.1.4), 
win be prompted for the follovnng information: 

RESPONSE 


Integer number 
Integer number 
Odd integer number 
Even integer number 


PROMPT 

INPUT PARAMETERS 
START ROW = 

NUMBER OF ROWS = 
START COLUMN = 
NUMBER OF COLUMNS = 
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In 

the user 



REDUCE 





3.4 PSPECT 


PSPECT 1s designed to produce a 2-D projection of a 3-D surface. 
Output is directed to a sequential devide or the TEKTRONIX graphics 
terminal depending on which version is used (11/70 or IMAGE-100). The 
surface to be displayed is defined by a 50 x 50 array of floating point 
words. The line of view of the output image is the 45° diagonal running 
from row 50, column 1 to row 1, column 50. The surface is also elevated 
along the line of view at an angle of 60°. 

I 

3.4J MAIN 

First the input image is read into a 50 x 50 integer array. 

The image is then tilted upward at a 60° angle and projected onto a 
vertical plane. The projected height is scaled upward by a factor of 
lOj and this scaled value is entered into a 50 x 50 array of 
floating point numbers. When completed this array contains the 
output buffer position of each node in the image. 

After projecting the input image the output image is gen- 
erated by interpolating between nodes to obtain intermediate points. 
Processing is done by diagonal starting with the upper left diagonal . 
Each diagonal is processed one node at a time starting at the lower 
left. 

For each diagonal the number of nodes is calculated using 
the FUNCTION NNODE. For each node in the diagonal slopes are 
calculated to the two nearest neighbor nodes in the next diagonal. 
These slopes are then used to define the connecting links betv/een 
nodes. Nine lines of output are generated between diagonals to 
display these links. As processing continues up each diagonal a 
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maximum height value is saved which defines the hidden point 
criterium. In constructing the output buffer if a point is en- 
countered which is lower than the current maximum for the diagonal 
this point is ignored as a hidden point. 

« 

3.4. 1.2 Cotronon Areas 

a. DATAB 

1. ARRAY (50,50) - integer array of image 
data before projection 


3. 4. 1.3 Vari afal es 

a. MAT (50,50) - REAL*4, image data after 
projection 

b. SLOPE (3,50) - REAL*4, slope information 
for each node in diagonal 

c. KEY (2) - REALH, slope information for 
one node 

d. ROW - REAL*4, row number in input image 

e. COL - REAL*4, column number in input image 

f. BUFF (1536) - output buffer 

g. NDIAG - number of diagonals in image 

h. NODE - number of nodes in diagonal 

i. II - row position of node 

j. J1 - column position of node 

k. NO - number of adjacent nodes 

l. MAX - maximum value in diagonal 
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3.4.2 NNODE 

NNODE is an Integer FUNCTION which returns the number of 
nodes in a given diagonal of a square matrix. 

3. 4. 2.1 Argument List 

a. H - order of matrix 

b. NO ~ diagonal number 

3.4.3 CONECT 

Subroutine CONECT accepts a matrix order, diagonal number, 

node number, and an input image. It returns the number of nodes 

1 

adjacent to the input node and the slope between the input node and 
each adjacent node. 

3. 4. 3.1 Argument List 

a. N - order of matrix 

b. IDN - diagonal number 

• c. NO - node number . 

d. A(50,50) - REAL*4, projected image 

e. SLOPE (2) - slope to each adjacent node 

f. NC - number of adjacent nodes (0-2) 

3. 4. 3.2 Variables 

a. IS - row number of node 

b. dS - column number of node 

c. II - row number of first adjacent node 

d. J1 - column number of first adjacent node 


e. 12 - row number of second adjacent node 

f. 02 “ column number of second adjacent node 

3.4.4 DETIJ 

Subroutine DETIJ accepts a diagonal number, node number, and 
matrix order and returns the row and column number of the node. 

3.4. 4.1 Argument List 

a. I - row number of node 

b. 0 - column number of node 

c. - number of diagonal 

I 

d. K - number of node 

e. N - square size 

3.4.5 IN21 

IN21 is an I/O routine which reads one line of image data 
and expands that data so that each pixel occupies a full {2 byte) 
word of storage. 

3. 4.5.1 Argument List 

a. BUFFI (512) - buffer for expanded data 

3.4. 5. 2 Common Areas 
None 

3. 4. 5. 3 Variables . 

a. BUFF2 (256) >- buffer for original data 

b, LUN - Logical Unit Number 
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3.4.6 0UT22 


0UT22 accepts a buffer of image data in the form of one 
pixel per full word, compresses the data to one pixel per byte and 
writes the compressed data to the output file. 

3.4.6. 1 Argument List 

a. BUFF (1536) - Data buffer 

3-4.6.2 Common Areas 
None 

3. 4.6.3 Variables 

a. LBYT - low order byte of compressed v/ord 

b. HBYT - high order byte of compressed word 

3.4.7 User's Guide 

PSPECT is initiated by MCR command RUN PSPECT$. All user- 
supplied information is requested in OPEN (see 2.1.4) and GTWND 
(see 2.16.4). 
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3.5 INTER? 


Subroutine INTER? interpolates point source data from up to six 
sources and returns a weighted value for a point which is a specified 
distance from each source. Weighting is done by an inverse distance 
equation. 


3.5.1 Argument List 

a. XN (6) - REAL''^4, input data from 6 sources 

b. XMULT (6) - REAL*4, distance from each source to desired 
point 

c. VALUE - REAL*4, weighted value 


3.5.2 Common Areas 
None 


3.5.3 Variables 

a. DEN - REAL*4j sum of distances 


INTERP 






3.6 BSTBND 


Program BSTBND (Best band) allows the user to perform an eigenvalue 
analysis of an image. The user is prompted to identify an image window 
on the screen of the Image 100 with the cursor. Subroutine COVAR cal- 
culates the four band mean vector and full variance/covariance matrix 
for the image window. Subroutine 6ETEIG uses the means and variance/ 
covariance matrix in an eigenvalue analysis. Subroutine GETEIG prints 
out and returns to the main program the eigenvalues and the correspond- 
ing orthonormal eigenvectors for the specific variance/covariance matrix. 
The user is then prompted to select a particular eigenvector to project 
the image on. Subroutine COMBIN performs the actual image projection. 

A new image is generated which corresponds to the 4D image projected 
onto a ID plane in the direction of the selected eigenvector. 

3.6.1 MAIN 

Entry point MAIN is a main driver for program BSTBND. The 
processing sequence controlled by MAIN isj 

1. Open I/O files, 

2. Select image window, 

3. Calculate variance/ covariance 

4. Perform eigenvalue analysis, 

5. Select eigenvector on which to project image, 

6. Project image onto vector 

7. Repeat steps 5 and 6. 

3. 6. 1.1 Common Areas 
None. 
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3. 6.1. 2 Variables 

a. MEAN (4) - REAL*4 - Vector of means 

b. VAR (10) - REAL*4 - Variance matrix stored in. 
symmetri c form 

c. EIBEN (4) - REAL^4 - Vector of eigenvalues 

d. EVEC (4»4) - REAL*4 - Vector of eigenvectors 

e. VEC (4) - REAL*4) - Work vector 

3.6.2 COVAR 

Subroutine COVAR allows the user to select a window of the 
Image displayed on the screen of the Image 100. The subroutine 
then accesses the window and calculates the variance/covariance 
matrix of that window. The 40 mean vector, variance/covariance 
matrix, and the number of pixels in the window are returned to the 
calling program, 

3,6. 2-1 Argument List 

a. MEAN (4) - REAL*4 - Mean vector 

b. VAR(IO) - REAL*4 - Variance/covariance matrix 

c. NUM - INTEGER*2 - Number of pixels 

3.6.2. 2 Common Areas 
a, DBUF 

1. - BUFl (256) - INTEGER*2 - Data buffer 

2. BUF2 (256) - INTEGER*2 - Data buffer 

3. BUF3 (256) - INTEGER*2 - Data buffer 

4. BUF4 (256) - INTEGER*2 - Data buffer 
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3. 6. 2. 3 Variables 

a. BUFF (256,4) - INTEGER*2 - Data area equiv- 
alenced to BUF1-BUF4. 

b. SUM (4) - INTEGER*4 - Intermediate storage of 
means 

c. SUM2 (10) - REAL*4 - Intermediate storage of 
variance matrix 

d. PIXl (4) - INTE6ER*2 - Intermediate storage for 

« 

gray values 

e. PIX2 (4) - INTE6ER*2 - Intermediate storage 
for gray values 

f. PI (4) - REAL*4 - Intermediate storage for gray 
values 

g. P2 (4) - REAL*4 - Intermediate storage for gray 
values. 

3.6.3 GETEI6 

Subroutine GETEIG acts as an interface beti-^een the main 
program and the eigenvalue analysis routine. Subroutine GETEIG 
begins by transferring the variance matrix to a work array. Sub- 
routine EIGEN is called to calculate the eigenvalues and eigenvectors. 
Subroutine LOCATE is used to decode the storage mode of the eigen- 
values and eigenvectors. The original variance matrix is printed 
out along with the eigenvalues and eigenvectors. 

3.6. 3.1 Argument .List 

a. NV - INTEGER*2 - Order of matrix (default of 4) 

b. VAR (10) - REAL*4 - Variance matrix 
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c- EIGVAL (4) - REAL*4 - Eigenvalues 
d. EIGVEC (4,4) - REAL*4 - Eigenvectors 

3.6. 3. 2 Common Areas 
None. 

3.6. 3. 3 Variables 

a. WVAR (10) - REAL*4 - Work vector 

b. WVEC (16) - REAL*4 - Work vector 

c. LINE (4) - REAL*4 - Work vector 

3.6.4 EIGEN 

Subroutine EIGEN computes the eigenvalues and eigenvectors 
of a real symmetric matrix. Subroutine EIGEN is an adapted version 
of an IBM Scientific Subroutine Package (SSP). 

3.6. 4.1 Argument List 

a. A (10) - REAL*4 - Original matrix in symmetric 
form, destroyed in computation 

b. R (16) - REAL*4 - Resultant matrix of eigenvectors 

c. N - INTE6ER*2 - Order of matrix A 

d. MV - INTEGER*2 - Input code, 0 to compute both 
eigenvalues and eigenvectors, 1 to compute only 
eigenvalues. 

3.6.4. 2 Common Areas 
None. 
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3. 6. 4.3 Variables 


None. 

3.6.5 

Subroutine LOG is an IBM utility subprogram used by the 
Scientific Subroutine Package. The function of the routine LOG is 
to allow for easy conversion from one storage mode to another by 
computing a vector subscribe for an element of a matrix. 


3.6.5. 1 Argument List 

a. I - INTEGER*2 - Row number 

b. <3 - INTEGER*2 - Column number 

c. IR - INTEGER*2 - Vector subscript 

d. N - INTEGER*2 - Number of rows in matrix 

e. M - INTEGER*2 - Number of columns in matrix 

f. MS - INTEGER*2 - Storage mode of matrix 

0 - General 

1 - Symmetric 

2 - Diagonal 

3.6. 5. 2 Common Areas 
None. 

3.6.5. 3 Variables 
None. 
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3.6.6 COMBIN 


Subroutine COMBIN is a general routine which allows cal- 
culation of a new image by forming a linear combination of four 
input images. The subprogram scans the input images forming the 
specific linear combination to identify an output maximum and 
minimum. The image is then generated and scaled accordingly. 

3. 6. 6.1 Argument List 

a. COEFF (4) - REAL*4 - Vector of coefficients 
defining the linear combination 

3. 6. 6. 2 Common Areas 

a. DBUF - See section 3. 6. 2. 2 

3. 6. 6. 3 Variables 

a. PIXEL - REAL*4 - Resultant gray value 

b. MAX - REALH - Calculated image maximum 

c. MIN - REAL*4 - Calculated image minimum 

d. GAIN - REAL*4 - Resultant gain for scaling 

e. BUFF (256,4) - See section 3.6. 2. 3 

3.6.7 User's Guide 

BSTBND is initiated by the MCR command RUN BSTBND$. In 
addition to the inputs required by GTWND (See section 2.16), the 
user would be prompted for the following: 

PROMPT . RESPONSE 

VECTOR NUMBER ? Integer between 0 and 4 
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3.7 MD 

See 4.9.3 

3.8 POLYGQ 

P0LY60 allows the user to produce a binary polygon map on any one 
of the theme planes on the IMAGE-100. Up to 20 polygon vertices may be 
indicated using the IMAGE-100 cursor. POLYGO will then connect adjacent 
vertices and fill in all enclosed points. 

3.8.1 HAIM 

MAIN acts only as a driver for all of the subroutines which 
make up POLYGO. First, the output buffer (for writing to theme 
plane) is cleared, 6ETPNT is called to input the vertices, BORDER 
is called to connect them, and SORT is called to sort the border 
points by ascending row. Finally FILLIN is called to fill in all 
enclosed points and write them out to the desired theme. At this 
point, the user has the option of restarting or exiting. 

3. 8. 1.1 Common Areas 
a. VTX 

1. POINT (2,1000,2) - Storage area for border 
" points. 

2. NPT - Number of points. 

3. VERTEX (2,20) - Storage area for vertices. 
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4, NVTX •* Number of vertices. 

5. LINK (21) - Link pointers used for merge 
sorting. 

b. DBUF 

1, BUFF (32) - Output buffer to theme. 

3.8. 1.2 Variables 

a. N - Indicates position of sorted point list (1 
or 2). 

3.8.2 GETPNT 

Subroutine GETPNT is an interface routine which allov/s the 
user to input vertices through the IfiAGE-100 cursor. The system 
subroutine IRK is used to read the cursor; as each point is read it 
is placed in the array VERTEX. GETPNT will automatically exit 
after 20 points or the user may exit before 20 points by repeating 
the last one. 

3.8.2. 1 Argument List 
None 

3.8. 2. 2 Common Areas 

a. NTHH 

1. THEME - Theme for output (1-8). 

b. DBUF - See 3. 8. 1.1 

c. VTX - See 3.8.1.1 
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3.8. 2,3 Variables 


a. 

X - last X value 


b. 

Y - last Y value 


c. 

XDIF - Current X minus 

last X 

d. 

YDIF - current Y minus 

last Y 

3.8,3 BORDER 




Subroutine BORDER accepts a list of polygon vertices in 
VERTEX and returns a list of border points in POINT. It also 
returns a list of link pointers (LINK) which indicate the position 
of each vertex in point. For each vertex the slope to the next 
vertex clockwise is calculated. The vertex and slope define an 
equation for a line into which known row values can be substituted 
to determine the column values of the border points. These points, 
generated in ascending row order for each side, result in a point 
list which is locally sorted by row. The link pointers indicate 
the limits of these sorted regions. 

3. 8.3.1 Argument List 

None 

3. 8. 3. 2 Common Areas 

a. VTX - See 3.8. 1.1 

3. 8. 3. 3 Variables 

a. SLOPE - REAL*A, slope between adjacent vertices. 

b. XREAL - REAL*4, computed column value. 

c. XI - Column value of vertex with lower row 
number. 
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d. Y1 - Row value of vertex with lower row number. 

e. X2 - Column value of vertex with higher row 
number. 

f. Y2 - Row value of vertex with higher row number. 


3.8.4 SORT 

Subroutine SORT accepts a locally sorted list of border 
points and a list of pointers indicating these local regions and 
returns a globally sorted list of border points. A merge sorting 
algorithm is used which requires two storage areas; hence, it is 
also necessary to return a flag v/hich indicates in which area the 
sorted array resides. 

A number of locally sorted groups is equal to the number of 
polygon vertices. Each adjacent pair is merged together by com- 
paring row values of the two top points in placing the point with a 
lower row value into the new area. This process continues until 
one of the groups is depleted, at which point the remaining group 
is simply transferred to the new area. Each pair of groups is 
merged in this fashion. If there is an odd number of groups the 
last one is transferred with no merging. At the end of each pass 
the number of groups is halved {except in case of odd group), so 
that the total number of passes as log^N where N is the initial 
number of groups. 

3. 8. 4.1 Argument List 

a. N2 - Array number (1 or 2) in which sorted list 
resides. 


3.8.4. 2 CotiTOon Areas 

a. VTX - See 3. 8. 1.1 

3. 8. 4. 3 Variables 

a. NGP - Number of groups in array, 

b. ODD - Indicate presence of odd number of groups. 

c. N1 - Old array number. 

d. II “ Number of group 1 (points into LINK). 

e. 12 - Number of group 2 (points into LINK). 

f. PI - Position pointer for group 1. 

g. P2 - Position pointer for group 2, 

h. INDX •* Position pointer for new array. 

3.8.5 FILLIH 

Subroutine FILLIN accepts the sorted list from SORT, determines 
the interior polygon points, and calls insert to produce a binary 
map on the IMAGE-1 00 screen. Filling takes place one row at a 
time, left to right. Each row is first sorted by ascending columns 
before filling takes place. The filling algorithm can be broken 
into three general cases: 

1. Only one point in row (must be a vertex) 

2. Two or more points in row - no vertices. 

3. Two or more points in row - one or more vertices. 

Treatment of cases one and two are straightforward. In case 

one a single point is written on the screen. In case two points 
one and two, three and four, five and six, etc., are connected 
(when no vertices are present there must always be an even number 
in points). 
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In case three complications can arise when a vertex is 
encountered. This can be broken again into three subcases. 

3A. The vertex is in a region which is monotonically in- 
creasing or decreasing. 

3B. The vertex is a local maximum, or minimum. 

3C. The vertex marks the transition from a positive or 
negative slope to a zero slope. 

Case 3A requires that the vertex be treated as a normal 

4 

border point. When a border point is encountered and the print 
switch is off, the point is saved as a print switch initiator and 
the print switch is turned on. When a border point is encountered 
and the print switch is on, the points between the previous point 
and the current point are filled after which the print switch is 
turned off. At the beginning of each new row the print switch is 
off. 

Case 3B causes no change in the print switch. If the print 
switch is off, the vertex is output as a single point. If the 
print switch is on, the vertex is ignored because it will be filled 
when the next border point is encountered. 

In case 3C a zero slope is encountered and the slope must 
remain zero until another vertex is encountered. Hence, the next 
point in the row must also be a vertex and filling must take place 
between these adjacent vertices. Therefore, if the print switch 
was initially on it is left on and the first vertex is ignored. If 
the print switch was off it is now turned on and the position of 
the first vertex is saved as the print switch initiator. 

Now the second Vertex is considered. This vertex has two 
adjacent vertices, one of which is the other half of the zero slope 
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pair. The adjacent vertex of Interest is the one which is con- 
nected with a non-zero slope. At this point one of two courses is 
taken ’depending on the sign of the slope and the position of this 
adjacent vertex. 

1. Turn off print switch fill between column where switch 
was initiated and second zero slope vertex. 

2. Leave print switch on, go to next point. Course one is 
taken if either 1) the adjacent vertex is on clockvnse 
side with the negative slope or 2) the adjacent vertex is 
on the counter clockwise side with a positive slope. 
Course two is taken if 1) the adjacent vertex is on the 
clockwise side with a positive slope or 2} the adjacent 
vertex is on the counter clockwise side with a negative 

' slope. Filling continues until all rows have been pro- 
cessed; control is then returned to MAIN. 

3.8.5. 1 Argument List 




PT (2,1000) - Sorted list of border points 

3.8. 5. 2 

Common Areas 


a. 

VTX - See 3.8. 1.1 


b. 

DBUF - See 3. 8. 1.1 


c- 

NTHM - See 3. 8. 2. 2 

3.8. 5. 3 

Variables 


a. VTXR (5) - Storage compositions of vertices in 
current row. 

b. INDEX - Position pointer in sorted array. 
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c. NPR - Number of points in current row. 

d. NVR - Number of vertices in current row. 

e. ROW - Current row number. 

f. COL - Current coltunn number. 

g. PSW - Print switch. 

H. LASTC - Print switch initiator column number. 

3.8.6 INSERT 

Subroutine INSERT accepts two column numbers, COLl and C0L2. 
It turns on all bits in the output buffer between these two columns 
inclusively. The output buffer for writing through themes consist 
of 32 two-byte words; therefore there are 512 bits, one per column. 

First COLl is checked for invalid values, then the word (1- 
32) and bit (1-16) positions for that column are calculated. If 
C0L2 is less than or equal to COLl the bit corresponding to COLl is 
turned on and insert returns. Otherwise, all intermediate bits are 
-turned on. Buffer words which are completely contained within the 
column limits are logically ORed with the logical mask 177777. 
^Words which are to be partially filled are processed using the 
function FILL. 


3.8.6. 1 Argument List 

a. COLl - Column for start fill. 

b. COLE - Column for end fill. 

3.8.6. 2 Common Areas 

a. DBUF - See 3. 8. 1.1 
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3.8. 6. 3 Variables 

a. TEMP - Template for inserting simibol bit. 

b. WORD! - Number of word contained in COLl. 

c. BITl - Bit position of COLl in word number 
WORDl. 

d. MASK - Logical ir^ask for insertion. 

e. W0RD2 - Number of word containing C0L2. 

f. BIT2 - Bit position of C0L2 in word number 
W0RD2. 

g. N - Number of words between WORDl and W0RD2. 

3.8.7 FILL 

FILL is a function subprogram which accepts two-bit posi- 
tions and returns a logical mask which has those two bits and all 
bits between turned on. The total number of bits to be inserted is 
calculated and this number is used as an upper limit in a DO loop 
vjhich performs a shift left one, add one operation. This enters 
the proper number of bits into the mask. The bits are then posi- 
•fioned correctly by shifting left (no add) a number of places equal 
to the bit number of the right -most bit. 

3.8.7. 1 Argument List 

a. BITl - Bit number of left-most bit, 

fa, BIT2 - Bit number of right-most fait. 

3. 8. 7. 2 Common Areas 


3.S.7.3 Variables 


a. NUM - Total number of add-shift operations. 

b. TEMP - Initial template. 


3.8.8 User's Guide 

POLYGO is initiated by the HCR command PvUN POLYGO $. At 
execution time the user v/ill be prompted for the following infor- 
mation. 


PROMPT RESPONSE 

THEME NUMBER? > Integer Value (1-8) 

CURSOR > Position Cursor# press 

carriage return to input vertex. 
Repeat last vertex to exit loop 


(R) ESTART OR (E) XIT? > 


R or E 


POLYGO 



A-106 















ENTRY SORT 


NEXT 2 GROUPS 


<:alcolate ^ 

OF GROUPS 
TORE MERSEO 



-COMPARE 
ROW value 
OFTOP POINTS 
IN GROUPS 1 & E 




POP REMAINDER 
OF GROUPS 
PUSH ON TO STACK] 


POP GROUP! 


POpQHoupa 

PUSH ON 


PUSH ON 

TOSTAOK 


TO STACK 



NO 


POP REMAINDER 
OF GROUP! 

I PUSH ON TO STACK 


MARK 
NEW GROUP 
ON STACK 


NO 



Gl?' Tip 

' PAGE 


YES 
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3.9 SHADE 


SHADE accepts an input window in image format with a maximum number 
of 250 columns and produces a shade print map of the image on a line 
printer. Shade requires a spooled line printer which is capable of 
printing at eight lines per inch. 

Shading is accomplished by using triple strike characters. Two 
logical units are assign to LP:, one for each 125-character strip. Two 
options are available for choosing the character set. 

1. Character set input manually through terminal. 

2. Character set is assigned by program after scanning the image, 

3.9.1 MAIN 

MAIN opens the input data set and then calls GTWND to get 
the window coordinates. The user is then prompted for the char- 
acter set option. If he chooses option one, GETSET is called and 
the character set is input from the terminal. If option two is 
chosen, SKP is called to position the file, AUTOST is called to 
scan the image and assign the character set, and REREAD is called 
to reposition the file. Next, headers are written on the shade 
print and SKIP is again called to position the file at the be- 
ginning of the window. 

I/O on the input file is performed with double buffering, so 
an initial call to READER is required before entering the loop 
Which performs the actual processing. Upon entering the loop WAIT 
is called to wait for I/O completion and READER is called again to 
fill buffer number two. CRUNCH is now called to process buffer 
number one and produce one line of shade print. Next, WAIT is 


called to wait for buffer number two, after which buffer number one 
is refilled by another call to READER. Buffer number two is 
processed by another call to CRUNCH and the loop restarts. After 
exiting from the loop, HHIST is called to produce a histogram of 
the input image on the line printer. The input 1s rev/ound in RWND 
and the task exits, 

3.9. 1.1 Common Areas 

a. LUN 

1. LUNI “ Input image Logical Unit Number 

2. LUNO - Not used 

3. NIN - Not used 

4. NOUT - Not used 

b, ARRAY 

1* ARRAl (250) - Output buffer number 1 for 
LP: 

2. ARRA2 (250) - Output buffer number 2 for 

^ ^ IP: . . ' 

3. ARRAS (250) - Output buffer number 3 for 
- IPt 

4. HIST (256) - Image histogram. 

■■ c.- ‘ 

. 1. VALUEl (256) - First strike character set. 

2. VALUE2 (256) - Second strike character 
set. 

3. VALUES (256) - Third strike character set. 


d, IT125 

1. CHECK - Flag, less than or equal to zero if 
number of columns is less than or equal to 
125, greater than zero if number of columns 
greater than 125. 

2. N *• last column of first strip- 

3. COLSUM - Total number of columns output. 

4. lABELR - Current row number. 

e. WINDIN 

1. ROW - Start row. 

2. ROWSUM - Number of rows. 

3. COLUMN - Start column. 

4. NCOLS - Number of columns. 

3. 9. 1.2 Variables 

a. LINE (256,2) - Two input buffers. 

b. IVAL - Stores ASCII code for blanks, used for 
output formating. 

c. LRECL - Maximum logical record length of input 
file. 

d. NSKIP *> Number of rows to be skipped. 

e. KI - Actual input logical record length. 

3.9.2 GETSET 

GETSET provides a user interface for inputting the character 
set through the CRT. The user is prompted from the first 256 
characters which make up the first of the triple strike character 



set. The user types in any printable ASCII character followed by a 
repetition factor. After receiving 256 characters, GETSET will 
begin to prompt for the second set and then the third. 

3.9.2.1 Argument List 

a. V(256,3) - Storage array for three 256-char- 
acter vectors. 

3.9. 2.2 Common Areas 

None 

3.9.2.3 Variables 

a. HUM (3), IIfTEGER*4, stores header information. 

b. CHAR - ASCII character for input into character 
set. 

c- REP - Number of times CHAR is to be repeated. 

3.9.3 AUTOST 

AUTOST provides a means for assigning a standard character 
set through a given input inage. The image is first scanned using 
subroutine SCAN and a histogram is accumulated of every fifth pixel 
In every fifth rovy. The histogram is then divided into eight 
equally populated regions to which each Is assigned one of the 
eight standard triple strike characters. 

3. 9.3.1 Argument List 

a. y(256,3) - Storage array for three 256 -char- 
acter vectors. 
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3. 9.3, 2 Common Areas 


a. WINDIN - See 3.9.1.1 

b. ARRAY - See 3. 9. 1.1 


3. 9.3.3 Variables 

a. ISUM - Total histogram population. 

b. DIV ~ REAL*4, inverse of 1/8 of total histogram 
population, 

c. CHAR (3,8) - Stores eight standard triple 
strike characters. 

d. V - REAL*4, floating point equivalent of ISUM. 

e. ZZ - REAL*4, character number to assign to gray 
value. 

f. NCH - Integer equivalent of ZZ. 

3.9.4 CRUNCH 

Subroutine CRUNCH accepts one line of the input image, 
performs a table lookup into the character set using each gray 
value as an index, and constructs three buffers, one for each 
strike, for output to the line printer. As the processing takes 
place a histogram is also accumulated. 

3.9. 4.1 Argument List 

a, BUFFER (M2) - Image buffer. 

fa. Ml - First word to be processed in buffer. 

c. M2 - Last word to be processed in buffer. 
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3. 9. 4.2 Common Aveas 

a. VAL- See 3.9. 1.1 

b. ARRAY » See 3.9.7. 1 

c. LT125 - See 3.9,1 .1 

3. 9.4.3 Variables 

a. KK - Position pointer for output buffers. 

b. INEW “ Index for table lookup, 

3.9.5 User's Guide 

Shade is initiated by the MCR command RUN SHADE$. In ad- 
dition to the information required by OPEN {Section 2.1 .4) and 
GTWND (Section 2.16.4), the user will be prompted for the follow- 
ing information. • 

PROMPT RESPONSE 

USE DEFAULT CHARACTER SET? > Y or N 

If the default character set is not desired the user must 
enter the character set on the control terminal. 

PROMPT RESPONSE 

{ TST/2ND/3RD) CHARACTER SET 

CHARACTER? > Any Printable ASCII Character 

REPETITION? > Integer Value (1-256 ) 

Shade v/ill continue prompting until all three character sets 
are filled. 
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3.10 EDGE 


EDGE Is s multi-purpose task which all ov/s the user to replace each 
pixel in an image with a linear combination of the pixels in a 5 x 5 
area centered around that pixel- Any linear combination using integer 
values is possible; thus the program can be used for edg*e enhancement, 
smoothing, or averaging, line enhancement, etc. 

Two options are provided for the definition of the 5x5 kernel. 

The first option allows the user to specify an angle of edge enhancement 
from which the kernel is computed. The second option allows the user to 
manually specify each element of the 5x5 kernel. Both options also 
required a normalizing factor and an offset value so that the final 
pixel replacement value is 

P = (K + 0) N 

where K is the result obtained fay applying the 5x5 kernel, N is 
normalizing factor, and 0 is the offset. Any negative values are 
replaced by 0 and values over 255 are replaced by 255. 

3.10,1 MAIN 

First the user is prompted for the desired option number. 

For option number one SETKER is called and for option number two 
RDKER is called. When control returns to MAIN the kernel is typed 
on the screen of the terminal and the user has the option of cpn- 
tiniiing or exiting. If he desires to continue he is prompted for 
the normalizing factor, and offset GTWND is called to get the 
window coordinates and OPEN is called twice to open the input and 
output files. Finally, CQNVLT is called to produce the output 
image. 
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3.10.1.1 Common Areas 

a. LUN 

1. LUNI - Input image Logical Unit Number. 

2. LUNO - Output image Logical Unit Number, 

3. NIN - Not used. 

4. NOUT - Not used. 

b. WIMD 

1. WROW - First row of input image. 

2. NROWS - Number of rows of input image. 

3. NCOL - First column of input image. 

4. NCOLS - Number of columns of input image. 

c. KERN 

1. KER (5,5) - 5 X 5 kernel. 

2. XNORM - Normalizing factor. 

3. OFFSET - Offset values. 

3.10.1.2 Variables 

.a. OPTION - Option number (1 or 2). 


3.10.2 SETKER 

Subroutine SETKER prompts the user for a desired angle of 
enhancement and calculates a 5x5 kernel which will enhance edges 
which lie on or near that angle. A kernel will smooth in the 
perpendicular direction. 

3.10.2.1 Arguments . 
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None 


3.10.2.2 Coimnpn Areas 

a. KEM - See 3.11.1,1 

3.10.2.3 Variables 

a, ANGLE - REAL*4, Angle of enhancement. 

b, G - REAL*4, Cosine of ANGLE. 

c, S - REAL*4, Sine of ANGLE. 

3.10.3 RDKER 

Subroutine RDKER allows the user to manually type in any 
5 X 5 kernel , one rovj at a time. 

3.10.3,1 Arguments. 

None 

3»10«3.2 CoiOTon Areas 

a. KERN - See 3,11.1.1 

.3.10.4 COHVLT 

Subroutine GONVLT applys to previously defined kernel to the 
Input image and produces the output image. Five lines of the input 
image are needed to produce a line of the output image; therefore, 
i'ive input buffers are needed. 

■After calculating the buffer length the first five lines of 
the input are read. After each line is read it is expanded to one 
pixel per full word format, in STRETCH. Next the main loop v^here 
the processing takes place is entered. First READER is called to 
issue an I/O request for a hevj input line which will be used the 
next time through tfne loop. The kernel is now applied to the five 
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lines which have already been expanded* As each new pixel is 
generated it is checked for a negative value. All negative pixels 
are set to 0. Then the pixel is divided by the normalising factor 
end the results are checked fot a value greater than 255. If found 
the pixel is set equal to 55 to avoid wrap around. 'STORIT is 
called to place the new pixel in the correct position of the output 
buffer. After the new line is completed the buffer pointers which 
Indicate the order in which the buffer v;ere filled are rotated and 
WRITER is called to write the new line. After the entire window 
has been processed, EOF is called to write an end of file mark on 
the new file, and both input and output files are rewound. 

3.10.4.1 Argument List 

None 

3.10.4.2 Conroon Areas 

a. LUN - See 3.11.1.1 

b. KERN - See 3.11.1.1 

c. POINT 

1. 11- Buffer pointer number one. 

2. L2 - Buffer pointer number two. 

3. L3 - Buffer pointer number three. 

4. L4 - Buffer pointer number four. 

5. L5 - Buffer pointer number five. 

d. DBUF 

1. BUFFI (256) ~ Input buffer. 

2. BUFF2 (256) - Output buffer. 

e. WIND ~ See 3.11.1.1 
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3,10.4.3 Variables 

a, BLEN - Output buffer lengths. 

b. BUFLEN - Input buffer lengths, 

c, PI)EL (512,5) - Expanded input buffers. 

d. ISUH - Weiif gray value. 

3.10.5 ROTATE 

Subroutine ROTATE cycles the buffer pointers which indicate 
which input line is contained in each buffer. 

3.11.5.1 Argument List 
None 

3. 10.. 5. 2 Common Areas 

a. POINT - See 3.11.5.2 

3.10.6 STRETCH 

Subroutine STRETCH accepts a line in the input image in the 
forat of one pixel per byte and expands it into lije form of one 
pixel per word. 

3.10.6.1 Argument List 

a. BUFFIN (256) - Input buffer, 
fa. LINE (Dl,D2) - Output buffers, 

c. NUH - Number of output buffer to be filled. 

d. D1 - Output buffer dimension number one. 

e. D2 - Output buffer dimension number two. 
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3.10.6.2 Common Areas 

a, WIND -See 3.11.1.1 

3. 10.6.3 Tariables 

a. MWORD - Number of words to be processed. 

3.10.7 STORIT 

Subroutine STORIT accepts a pixel in a buffer position and 
inserts that pixel in the specify position of the output buffer. 

3.10.7.1 Argument List 

a. FIX - Pixel to be stored. 

b. NUM - Column number of pixels. 

3.10.7.2 Common Areas 

a. DBUF - See 3.11.5.2 

b. WIND - See 3.11.1.1 

3.10.7.3 Variables 

a. INDX -Output word number of pixels. 

3.10.8 User's Guide 

EDGE is initiated by the MCR command RUN EDGE$. In addition 
to the Information requested by OPEN (Section 2. 1.4) and GTWND 
(Section 2. T6. 4) , the user will be requested to supply the follow- 
ing information. .. 


PROMPT 


RESPONSE 


OPTION DESIRED? > 
if option one 1s chosen 

ENHANCEMENT ANGLE (®) = 
if option two is chosen 
FIRST ROW > 

SECOND ROW > 

THIRD ROW > 

FOURTH ROW > 

FIFTH ROW > 

for both options 

NORMALIZING FACTOR? > 

OFFSET? > 

TYPE IN ORIGINAL MINIMUM AND 
MAXIMUM GRAY VALUES > 

TYPE IN FINAL MINIMUM 
AND MAXIMUM GRAY VALUES > 

for option #5 

SPREAD FACTOR? > 


1 or 2 


Floating point value 


5 integer values separated 
by commas. 

5 Integer values separated 
by commas. 

5 integer values separated by 
commas. 

5 integer values separated by 
commas^ 

5 integer values separated by 
commas . 


Integer value. 
Integer value. 


Integer (0-255), Integer 
(0-255) 


Integer (0-255), Integer 
(0-255) 


Integer (1-100) or carriage 
return for default of 66^ 


EDGE 














CONVLT 


ENTRY CONVLT 


CALCULATE 
BUFFER LENGTHS 
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3.n HHIST 


Subroutine HHIST accepts as input a 256 - bin histogram which it 
displays in graphic form. There are 128 columns of histogram output, so 
pairs of consecutive bins in the original histogram are merged to form 
one column of output. The histogram output contains a fixed number of 
rows, and the subroutine will automatically scale the data to fit in the 
allotted space. This scaling is effected by setting each character on 
the histogram equal to a certain number of occurrences. The number of 
remaining pixels in each bin (once the largest possible multiple of the 
sealing factor has been subtracted) is shov/n by a character on top of 
each bin in the printed histogram. 

3.11.1 Argument List 

a. HIST (256) - input histogram 

3.11.2 Common Areas 

None 

3.11.3 Variables 

a. NHAX ^ maximum value of histogram 

b. ING - histogram scale factor 
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3.12 REGIST 

See AFYNE (4.9.2) 

3.13 CONTOURS 

See GRAY (3.1) 

3.14 LINE 

See EDGE (3.10) 

3.T5 COMBINE 

See BESTBAMD (3.6) 


4.0 DATA MANAGEMENT SOFTWARE 

4.1 CINDEX 

CINDEX contains the initial steps of the data base creation se- 
quence, creation of the label and index file. The program accepts the 
data base dimensions in the form of maximum and minimum coordinates. 

From this information, the storage requirements are calculated and 
displayed on the terminal. At this point, final operator approval is 
necessary for file generation- Upon approval, the label file is created 
and the index file label is inserted. Finally, the index file is created 
and the header and one 8-byte record for each I,J is inserted. 

4.1.1 Common Areas - None 

4.1.2 Variables 

a. LBLl (4) - LOGICAL*!, Use to store ASCII file type 
qualifier '-LBL' 

b. LBL2 (4) - LOGICAL*!, used to store ASCII file type 
qualifier ' *IDX' 

c. FILE (18) - LOGICAL*!, ASCII file name 

d. IHIN - Minimum I value in data base 

e. NUHI - Number of I values in data base 

f. JMIN - Minimum J value in data base 

g. NUMJ - Number of d values in data base 

h. NBLK - Number of blocks of index file storage 

i. IDEV- ASCII device name 

j. IUN6 - Physical device number 

k. LUN - Logical Unit Number 

l. LRECP - Index fild record length 
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m. NREC - I NTE6ER*4, number of records in the index file 
n* NBYT - INTEGER*4, number of bytes 1n the index file 
0 . BUFF (2) - INTEGER*4, I/O buffer for index file 
, V “ INTEGERS, associate variable for index file 


4,1.3 User’s Guide 
PROMPT 

MINIMUM I VALUE?> 
MAXIMUM I VALUE?> 
MINIMUM J VALUE?> 
‘ MAXIMUM d VALUE?> 
CONTINUE?> 

DATA BASE NAME?> 
DEVICE?> 

UNIT NUM8ER?> 


RESPONSE 

Three-digit integer value 
Three-digit integer value 
Three-digit integer value 
Three-digit integer value 
Y or N 

Nine-character ASCII name 
Two-character ASCII device name 
Physical unit number of device 



CINDEX 







4.2 POLYB 


POLYB accepts the LAT, LON vertices of each sub-basin in the water- 
shed area, determines v/hich cells lie within each sub-basin and inserts 
the basin's numbers in the index records, CINDEX must be run before 
running this program. 

4,2.1 MAIN 

For each sub-basin, POLYB will ^accept up to 20 vertices in 
the form of latitude and longitude. Each vertex is transformed 
into 1,0 coordinates which are multiplied by two before truncation 
to preserve the K coordinates. Next, adjacent vertices are con- 
nected using subroutine BORDER. Subroutine SORT sorts all border points 
by 0 number and subroutine FILLIN fills in interior points for each 
0 row. These three subroutines are described in Section 3.8 under 
P0LY60. 

As each row is filled-in, subroutine INSERTS is called to 
enter the basin numbers in the index file. This subroutine is 
passed an initial I, a final I, and a J value, each doubled to 
preserve K values. INSERTS determines which K cells lie within the 
specified limits and inserts the current basin number in the index 
record for each of them. After each sub-basin is complete, the 
user has the option of restarting or exiting. 

4. 2. 1.1 Common Areas 
a. ..VTX 

1. POINT (2,1000,2) - Storage for up to 1,000 
border coordinate pairs 


2. NPT - Number of coordinate pairs stored in 
POINT 

3. VERTEX (2,20) - Used to store up to 20 
vertex coordinate pairs 

4. NVTX “ Number of vertex co’ordinate pairs 
stored in VERTEX 

5. LINK (21) - Points into POINT for purposes 
of merge sorting 

b. INDEX 

1, NRECP - INTEGER*4, number of records in-' 
index file 

2. P - INTEGER*4, associate variable for the 
index file 

.3. LUNI - Logical Unit Number 

4. LRECP - Record length of index records 

5. IMIN “ First I value in index file 

6. NUMI - Number of I values in the index 
file 

7. OMIN - First «3 value in index file 

8. NUMJ - Number of J values in index file 

4. 2.1*2 ^t/ariables 

a. PTl (2,1000) - Array used by EQUIVALENCE state- 
ment to format POINT 

b. PT2 ( 2 ^ 1000 ) - Array used by EQUIVALENCE states 

ment to format POINT 

e. N « Used by SORT to indicate in which half of 

POINT the sorted array resides 
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4.2.2 GETPNT 


GETPNT is an interface module v/hich accepts a basin number 
and a set of basin vertices in the form of latitude and longitude 
coordinates. As each coordinate pair is accepted j it is mapped 
into the WHO grid. The resulting floating point I,J pair is 
multiplied by tv'^o before being converted into integer in VERTEX. 
This avoids truncation of the fraction which determines the K cell 
number. 

4.2.2. 1 Agrument List 

None 

4. 2.2.2 Common Areas 

a. VTX •* See 4.2.1.1 

b. NTHM 

1. THEME - Not used in this task 

2. NBASIN - Basin number of polygon 

4.2. 2. 3 Variables 

a. IPT - Stores unsealed I coordinate for output 
to terminal 

■ b. OPT - Stores unsealed J coordinate for output 
to terminal 

c. XLAT - REAL*4, latitude of basin vertex 

d. XLON - REAL*4» longitude of basin vertex 

e. XB - REAL''"4a conversion constant used for 
mapping into WHO grid 

f. X ~ REAL*4, conversion constant used for map- 
ping into WHO grid 
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g, XI - REAL*4s result of WHO mapping, I coor- 
dinate 

h. XJ - REAL*4, result of mapping, J coordinate 

4.2.3 INSERT 

INSERT accepts first and last I values and a J value, de- 
termines v;hich K cells lie v/ithin these bounds and inserts the 
appropriate basin numbers in the index file for these cells. The I 
and J values as received by INSERT are doubled and the true 
are extracted as follows: 

I = 1 72 
J - 072 

Next INSERT determines if the first r,J is completely contained in 
the rov.’. If K equals two or three, the cell is completely contained 
and basin numbers may be inserted in both. If K equals one or 
four, only half the cell is contained. Interior cells are obviously 
completely contained. The last I, J is the reverse of the first. 

If K equals one or four, the cell is completely contained and if K 
equals two or three, it is only partially contained. 


4.2. 3.1 Aqrument Li st 

' a. COLl - First I coordinate 

b. C0L2 - Last I coordinate 

c. J - J coordinate 
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4.2.3. 2 Coniinon Areas . . 

a. INDEX - See 4.2.1. 1 

b. NTHM “ See 4. 2.2,2 

4.2.3.3 Variables ■ ' 

a. lOFF ~ INTEGER*4 5 points to record number in 
Index file of beginning of current J row 

b. MASK (2) - Logical masks 

c. HBASIN (2) - Logical masks used to insert basin 
number in either high order byte or low order 
byte of a word 

d. KBASIN - Stores basin number in both high and 
low order bytes, 

e. IFIRST - First I coordinate of row 

f. ILAST - Last I coordinate of row 

g. OROW - 0 coordinate of row 

h. KCOLl - Flag, equals zero if COLl is even, 
equals one if COLl is odd 

i. KC0L2 - Flag, equals zero if C0L2 is even, 
equals one if C0L2 is odd 

. J. KROW > Flag, equals zero if J is even, one if J 
; "js 'Odd. ■; 

k. INDX - Pointer into I/O buffer for index file. 
Points to first word if K equals one or two, 

• second word If K equals three or four 

l. BUFF (4) - I/O buffer for index file 

m. NDX - Pointer into HBASIN and MASK vectors 
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4.2.4 User»s Guide 


PROMPT 

DATA BASE NAME?> 

DEVICE NAHE?> 

UNIT NUMBER?> 
BASIN NUMBER?> 
LAT,LON?> 


RESPONSE 

NiiiG-character alphanumeric 
name 

Two-character alphanumeric 
name 

One-digit integer 

Integer number (1-8) 

Two. floating point numbers 
. (FI 2.4) separated by a comma or 
carriage return to exit 






















4.3 CDATA 


CDATA is used to generate the archive and daily cell files either 
simultaneously or individually. The program assumes that the index file 
has been created and the basin keys have been inserted. 

CDATA first searches the index file to determine the populated 
IjJ's. This information along with the record length and number of 
dates (for daily), is used to define storage requirements. Then de- 
pending on user inputs, the program proceeds to create the archive or 
daily files or both, inserting one record with I,J,K and basin numbers 
for each K cell (and for each date in daily files). 

4.3.1 Common Areas - None 

4.3.2 Description of Variables 

a. FILE (18) - LOGICAL*!, stores ASCII file name 

b. LRECA - Archive record length 

c. IDEV - ASCII device name 

d. lUNT - Physical device number 

e. BUFF (40) - I/O buffer 

f. LRECD - Daily record length 

g. NDAT - Number of dates in daily file 

h. IMIN - Minimum I value 

i. JMIN - Minimum J value 

j. NUMI - Number of I values 

k. NUMJ - Number of J values 

l. B12 - Basin numbers for iC equals one and two 

m. B34 - Basin numbers for K equals three and four 

n. NRECP - INTEGER*4, number of records in index file 

0 . NRECO - INTEGER*4, number of records in daily file 


p. NRECA - INTEGER*4, number of records in archive file 

q. NWORDA - INTE6ER*4» number of words in archive file 

r. NWORD - INTEGER*4, number of v/ords in daily file 

s. HRECPD - INTEGER*4, number of records for each date in 
daily file 

t. RNUM - INTE6ER*4» record number from index file 


4. 3. 3 User's Guide 
PROMPT 

DATA BASE NAME?> 

DEVICE NAHE?> 

UNIT NUMBER?> 

CREATE ARCHIVE FILE?> 
ARCHIVE RECORD LENGTH 
(DOUBLE WORDS )?> 

CREATE DAILY FILE?> 

DAILY RECORD LENGTH 
(DOUBLE WORDS )?> 

NUMBER OF DATES DE5IRED?> 


RESPONSE 

Nine- character alphanumeric 
name 

Two-character device name 
Integer number 

Y or N 

Integer number 

Y or N 

Integer number 
Integer number (1-31) 
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4.4 NBAS IN 


NBASIN traverses both the archive and the daily file and inserts a j ' 

direct access pointer in each record, which when added to the current t 

. i ■ ■■ 

record number vn 11 show the position of the next record within the same | 

basin. • . | 

I I , 

■ ' , r * ' 

4.4.1 Common Areas 

a. ARCHV ^ ' 

1. NRECA - INTEGERH, number of records in archive file ; 

2. A - INTEGER*4, associate variable for archive file 

3. LUNA - Logical Unit Number for archive file ! 

4. LRECA - Archive record length 

b. DAILY I 

1. NRECD - INTEGER*4, number of records in daily file ^ 

2. D - INTEGERS, associate variable for daily file 

3. NRECPD - INTE6ER*4, number of records per date ; 

4. LUND - Daily file Logical Unit Number 

5. LRECD - Daily record length 

6. NDATES - Number of dates in daily file 

7. JDATE (31) - Julian dates contained in daily file 

4.4.2 Variables 

a. LAST (10) “ INTEGER'^4, saves record number in which basin 

number (1-10) was last encountered 

b. NREC - INTEGER^, current record number 

c. DREG - I NTE6ER*4j record number for key insertion 

d. BASIN - Basin number (ASCII) 

e. BNUM - Basin number in binary 

f. BUFF (40) - I/O buffer 

, , ■''- 156 .:. 'y ^ 
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4,5 OPENPT 


OPENPT contains several entry points which open the data base file 
and process the file labels and header records. The four entry points 
are OPENB, OPENPTs OPENAR, and OPENDY. Each Will be discussed separately. 


4.5.1 OPEMB 

OPENB must be called once before any of the other modules 

are accessed. OPENB accepts a nine-character data base name to 

■* 

which it appends the type qualifier '*LBL'. The resulting file 
name points to the data base label file. OPENB also accepts a two- 
character device name and an integer physical unit number to com- 
pletely specify the location of the data base. Subsequent calls to 
the other modules in this group vdll now refer to the data base 
defined in OPENB - this avoids the necessity of redefining the data 
base each time an individual member file (index, archive, or daily) 
is opened. 

4.5.1 .1 Argument List 
None 


4.5.1 .2 Common Areas 
None 


4.5.1 ,3 Variables 

a. Label (18) - LOGICAL*! , array into which the 
label .file may be misplaced 
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b. LBLl (4) - LOGICAL*!, array used to store the 
type qualifier **LBL' 

c. IDEV - Two-character device name 

d. HINT - Physical unit number 

4.5,2 OPENPT 

OPENPT opens the index file of the data base previously 
specified by OPENS on the Logical Unit Number LUN which is passed 
through the argument list. First, the label file is opened and the 
index file label is read. The label file contains the following 
information: 

1. Number of records in file 

2. Record length (v/ords) 

3. ASCII file name 

The label file is then closed and the file specified in the 
label is opened for direct access I/O. The header record specifying 
the dimensions of the index file is read, and this information 
along with the first two entries in the label is passed to the 
calling program through a common block. 

4. 5.2.1 Argument List 

a, LUN - Logical Unit Number 

4. 5. 2. 2 Common Areas 
a. INDEX • 

.1. NRECP - INTEGER*4, number of records in 
index file 

2. P - INTEGER*4, associate variable for the 
index file 

3. LUNI - Logical Unit Number 


4. LRECP - Record length of Index record 


5. 

IHIN - 

First I value 

6. 

imi - 

Number of I values 

7. 

JMIN - 

First J value 

8. 

NUMJ - 

Number of <3 values 


4. 5. 2. 3 Variables 

a. FILE (18) - LOGICAL*!, file name in ASCII 

4,5.3 OPENAR 

OPENAR opens the archive file of the data base in the same 
v;ay that the index file is open. However, the archive header 
record is blank so header processing is not necessary. 

4.5. 3.1 Argument List 

a. LUN - Logical Unit Number 

4. 5. 3. 2 Common Areas 
a. ARCHV 

1. NRECA - INTEGER*4, number of records in 
archive file 

2. A - INTEGER*4, associate variable of 
archive file 

3. LUNA - Logical Unit Number 

. 4... LRECA - Archive record length 


4,5.4 OPENDY 


OpENDY opens the daily file of the data base in the same way 
that the index file is opened. The daily file header contains the 
following information: 
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lOpuciBiLrry of Tjf 


1. Number of records for each date 

Z, Number of dates in file 

3. Pointer into date array indicating last date entered 

4. Array of dates contained in file 

Along with the logical unit number, a Julian date is passed 
in the argument list* OPENDY searches for this date in the array 
of dates and if it is found, the file is positioned to the start of 
that date. If the date is not found, the program will determine if 
there is room for a new date or if an old date will have to be 
deleted. No date creation or overwriting will take place without 
operator approval. If an old date is overwritten, all data entries 
other than the I,J,K numbers and the basin number are erased and 
the new date is inserted both in the header record and in each data 
record within that date. Also, the pointer indicating the last 
date entered is updated. 

4.5. 4.1 Aqrument List 

a. LUN - Logical Unit Number to be opened 

b. DATE - INTEGER*4, Julian date to be found 

(YYDDD) 

4.5. 4. 2 Common Areas 
a. DAILY 

' 1. NRECD - INTEGERS, number of records in 

file 

2. D. - INTEGER*4, associate variable of file 

3. NRECPD - INTEGER*4, number of records per 
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date 


4. LUND - Logical Unit Number 

5. LRECD " Record length (words) 

6. NDATES - Number of dates in file 

7. JDATE (31) “ Julian dates (ODD) contained 

in file ’ 


4.5. 4.3 Variables 

a. FILE (18) - LOGICAL*!, daily file name 

b. IDATE - Julian date, not including year 

c. LAST Points to last date entered in array 
JDATE 

d. ADAT (3) - Target array used for coding 
Julian date into six bytes ASCII equivalents 

e. BUFF (40) - I/O buffer 

























4.6 PLYDMP 

PLYDMP is the first step in preparing SMS-derived data for in- 
sertion into the data base. It is currently set up for the processing 
of precipitation estimate derived from visible SMS images, but it is 
designed to easily accommodate extension to other data types. 

The purpose of PLYDMP is to accept cloud polygon data (generated by 
P0LY60) from the theme planes of the Image-100 and converted to data 
which can be used fay the data base. For precipitation estimate the 
operator is prompted for the image date, precipitation interval, number 
of cloud polygons and the cloud types and amounts in each polygon. 

Cloud types and amounts are converted to precipitation estimates in a 
simple one-line equation as follows: 

P = X X + Kg X 

where P is the estimated precipitation, Kl, K2 and K3 are constants and 
Cl, C2 and C3 are the percentage amounts of cumulonimbus, nimbo stratus 
and cumul ous-congestus clouds respectively. As each estimate is derived 
the operator is given the opportunity to edit it with a new value or 
accept the estimate. 

Next the user is requested to type in the ground control points 
obtained from METPAK when the image was generated. These are used to 
define an afyne transformation to effectively register the image to the 
data base. 

After the image is registered the data is dumped to a disk file for 
processing on the 11/70. Three header records are generated. The first 
contains a user defined label, the Julian date, the number of polygons 
and the information type. This header has the same format for all 
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Information types. The second header contains the afyne coefficients 
for registration. The third header varies with information type and for 
precipitation data it contains the estimated precipitation for each 
polygon. Following the headers are 512 lines of image data which have 
been extracted from the theme planes. Each line contains 512 bytes, one 
per pixel, with the value of each pixel corresponding to the polygon 
number of that pixel. Polygon numbers are the same as the theme numbers 
and must be consecutive starting at theme number one. 

4.6.1 Common Areas 
None. 

4.6.2 Variables ' 

a. BUFF (256) - Output buffer for disk. 

b. MONTH (12) - Conversion table for Julian date. 

c. CAMT (3) - Cloud amount for types 1-3. 

d. TBUF (32) - Input buffer for themes. 

e. JDATE - INTEGERS, Julian date. 

f. PCP (8) - REAL*4, Estimated precipitation for eight 
polygons. 

g. K (3) - REAL*4, K coefficients for precipitation estimation. 

h. XF - REAL*4, Precipitation interval. 

i. NPLY - Number of polygons, 

j. ITYP - Information type. 

4.6.3 User's Guide ’ 

PL1(PDMP is initiated by the MCR command RUN PLYDMP$. The 

user will be requested to supply the following information: 
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PROMPT 


RESPONSE 


FILE NAME? > 

ENTER UP TO 34 CHARACTERS OF 
IMAGE IDENTIFYING INFORMATION > 

NUMBER OF POLYGONS? > 

INFORMATION TYPE? > 

IMAGE DATE? > 

PRECIP INTERVAL (HOURS)? > 
CLOUDS TYPE, AMOUNT? > 


File Name (1-33 characters) 
for output file. 

Self explanatory 
Integer (1-8) 

Carriage return for a list 
of types, one for precipitation 

MN,; DD, YY. 

Integer (1-24). 

Integer (1-7), Integer (1-100), 











4,7 PLYRD 


PLYRD is designed to process the polygon information which was 
previously generated by PLYDMP, It is presently able to process pre- 
cipitation estimates only. 

4 , 7.1 mm 

First the polygon file is opened and the first header is 
read to determine the information type and the image date. Then 
the index file is opened and the daily file is opened to the dates 
specified in the polygon header. The second header is read to 
obtain the image registration data. 

For precipitation data the third header is read and the 
precipitation estimates are transferred in ASCII in coded form to 
the array ADAT. ADAT is then passed to subroutine STASH which 
enters the data into the daily file. 

4.7.1. 1 Common Areas 
•a. PLYGN 

1, DATE - INTE6ERH, Julian date. 

2, LUN - Logical Unit Number. 

3. NPLY - Number of polygons. 

4. ITYP - Information type, 
b. DBUF 

1. BUFF (256) -Input buffer. 
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4. 7. 1.2 Variables 

a. ADAT (3,8) - Eight precipitation estimates in 
ASCII. 

b. NCHAR - Length of precipitation .ield in daily 
record. 

c. NSPACE - Position of precipitation field in 
daily record. 

4.7.2 OPENPG 

Subroutine OPENPG opens the polygon file and processes the 


first header record. 

4. 7. 2.1 

Argument List 


None 

4. 7. 2. 2 

Conrnon Areas 


a. DAILY 


1. NRECD - INTEGER*4, Number of records in 
daily file. 

2. D “ INTEGER*4, Associate variable of daily 
file. 

3. NREGPD - INTE6ER*4, Number of records per 
date. 

4. LUND - Logical Unit Number. 

5. NDATES - Number of dates. 

6. ODATE (31) - Julian dates in file. 

b, PLYGN - See 4. 7.1.1 

c. DBUF - See 4.7. 1.1 
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4. 7, 2. 3 Variables 

a. FILE (17) - Polygon file name. 

4.7.3 STASH 

Subroutine STASH reads the 512 lines of polygon data and 
Inserts the correct precipitation estimates into all four K-cells 
for each I, J within each polygon. STASH can also be used to insert 
other parameters by changing NCHAR and NSPACE which define the 
field size and position within the daily file record. 

After each line of data is read it is extended to one pixel 
per word format. The value of each pixel is checked to determine 
if it belongs to a polygon. If it does IJREG is called to get the 
I,J cell number of the pixel and the corresponding precipitation 
estimate Is entered into each populated K-cell of that I,J. 

4.7.3.1 Argument List 

a. ADAT (3,8) - Eight precipitation estimates in 
ASCII. 

b. NCHAR - Length of precipitation field in daily 
record. 

c. NSPACE - Position of precipitation field in 
daily record. 

4.7. 3.2 Common Areas 
a. INDEX 

T. NRECP - INTEGER*4, Number of records in 
index file. 


2. P - INTEGERM, Associate variable of index 
file. 

3. LUNI - Index file Logical Unit Number. 

4. LRECP - Index record length. 

5. IMIN “ Minimum I value. 

6. NUMI - Number of I values. 

7. JMIN - Minimum J value, 

8. NUMJ - Number of J values. 

b. PYLGN - See 4.7.1.1 

c. DBUF - See 4.7.1.1 

d. AFN 

1, V (3) " REAL*4, AFYNE coefficients, row 1. 

2, VV (3) - REAL*4, AFYNE coefficients, row 

2 . 


447.3.3 Variables 

a. START - INTEGER*4, Start row number in daily 
- ■file. 

b. BUFFO (40) - Buffer for daily file. 

c. BUFFW (512) - Expanded pixel buffer. 


4.7.4 EXPAND 

Subroutine EXPAND accepts a 512-byte buffer in the form of 
one pixel per byte and returns a 1024-byte buffer in the form of 
one pixel per word. 


4. 7. 4.1 Argument List 

a. BUFFP (256) - Input buffer. 

b. BUFFW (512) - Output buffer. 

4.7.5 IJREG 

Subroutine 10 REG accepts the row, column coordinates of an 
image pixel and returns the corresponding 1,0 cell numbers for that 
pixel. Registration is accomplished through an AFYNE transformation 
relating row column to latitude and longitude. The latitude and 
longitude can then be directly converted to the WMO grid coordinates. 

4. 7. 5.1 Argument List 

a. X - REAL*4, Rov; coordinate. 

b. Y - REAL*4, Column coordinate. 

c. XI - REAL*4, I coordinate. 

d. XO - REAL*4, coordinate. 

4.7. 5.2 Common Areas 

a. AFN - See 4. 7. 3. 2 

4. 7. 5. 3 Variables 

a. XLAT - REAL*4, Latitude coordinate of pixel. 

b. XLON - REAL*4, Longitude coordinate of pixel. 

4.7.6 User’s Guide 

PLYRD is initiated by the HCR command RUN PLYRD$. The user 
will be requested to supply the following information. 
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PROMPT 


RESPONSE 


DATA BASE NAME? > 9-Character Name 

DEVICE? > 2-Character Device Name 

UNIT NUMBER? > 1-D1git Integer 

POLYGON FILE NAME? > 33-Character File*Name 





















4.8 DISPLAY 


DISPLAY provides a visual display of any of the data parameters 
stored in the data base. The display is in image format with constant d 
values along each row, constant I values along each column, and one 
pixel per K-cell. - * 

4.8.1 MAIN 

First the data base index file is opened and the user is 
prompted for file type (archive or daily). The data file is then 
open for input and the image file is open for output. The user is 
then prompted for information type and display limits. Only data 
entries which lie within the limits are displayed. Thus if the 
user wanted to display all K-cells.with less then one inch of 
precipitation he would enter 0 as a display minimum and 1 as a 
maximum. 

The output file is then built, two lines at a time, in 
subroutine EXTRACT if the parameter is integer, subroutine FLTEXT 
if the parameter is real. 

4.8.1. 1 Common Areas 

a. INDEX - See 4.5. 2.2 

b. ARCHIVE - See 4. 5. 3. 2 

c. DAILY - See 4.5.4. 2 

4.8. 1.2 Variables 

a. BUFF (512,2) - Two output buffers. 

b, AOFF (10) - Archive record field positions. 

C. ASIZE (10) Archive record field sizes. 


d. DOFF (10) - Daily record field positions. 

e. DSIZE (10) - Daily record field sizes. 

f. AFLT (10) - For REAL parameters number of bytes 
after decimal point. 

g. DFLT (10) - For REAL parameters number of bytes 
after decimal point. 

4.8.2 EXTRACT 

Subroutine EXTRACT creates two lines of image data from a 
constant 0 row of the data base grid. The data can be extracted 
from either the archive or the daily files. 

First the output buffers are cleared and the index file is 
searched for the first populated cell in the J row. If a populated 
cell is found the data file is positioned and processed until the J 
coordinate changes. For each K-cell in the row the data parameter 
is extracted and compared with the data limits. If the parameter 
lies within the limits, 255 is inserted in the corresponding output 
buffer position. 


4.8-2.1 Argument List 

a. IFL - Flag, equals 0 for archive file equals V 
for daily file. 

b. QFFST - INTEGER*4, Number of records offset for 
a dally file. 

c. JNUM “ 0 coordinate to be extracted. 

d. NSPACE.- Position of data parameter. 

e. OUTBUF (512,2) - Output buffers. 

f. SIZE - Length of data parameter fields. 
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4. 8. 2. 2 Common Areas 


a. MAXMIN 

1. MAX ~ Maximum data value 

2. MIN - Minimum data value 

b. INDEX - See 4. 5. 2.2 

c. DAILY - See 4. 5. 4,2 

d. ARCHIVE - See 4.5. 3.2 

4.8.2. 3 Variab! es 

a. LUN - Data file Logical Unit Number 

b. LREC - Data file record length 

c. BYTES - Number of bytes to be decoded 

d. JLOC ~ INTE6ERH, Position of 0 row in index 
file 

e. RNUH “ INTEGER*4, Record number of data file 

f . TEMP - Extracted data parameter 

4.8.3 FLTEXT 

Subroutine FLTEXT is the functional equivalent of EXTRACT. 
Accepts that a floating point value rather than an integer is 
extracted from the data file. 

4.8.4 User Vs Guide 

DISPLAY is initiated by the MCR command RUN DISPLAY$. The 
user will be requested to supply the following information. 


PROMPT 


RESPONSE 


DATA BASE NAME? > 

DEVICE? > 

UNIT NUMBER > 

DISPLAY FROM ARCHIVE FOR DAILY? > 
TYPE? > 

MAXIMUM VALUE (INTEGER)? > 
MINIMUM VALUE (INTEGER)? > 
MAXIMUM VALUE (REAL)? > 

MINIMUM VALUE (REAL)? > 


9-Character Name. 

2-Character Devi ce Name . 

1-Digit Integer. 

Self explanatory. 

Integer Number Selected From 
Display list. 

Self explanatory. 

Self explanatory. 

Self explanatory.. 

Self explanatory. 
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4.9 ERTS 200 

ERTS 200 is a multi-purpose task which allows the user to register 
an image to the WMO grid* produce a WMO grid overlay on a theme plane of 
the IMAGE-100, and aggregate LANDSAT classification data for insertion 
into the data base. 

4.9.1 MAIN 

The function of MAIN is to prompt the user for the desired 
option, insure the processing is being done in the correct order, 
and to call the required subroutines to do the processing- Before 
available options are REGISTER, OVERLAY, INSERT and STOP. 

The REGISTER option calls subroutine AFYNE and allows the 
user to enter ground control points through the Image-1 GO cursor. 

The image is registered to the WMO grid through an AFYNE transformation 
FLIP is called to define the reverse transformation. The REGISTER 
option must precede all other options. 

The GRID option simply applies the transformation defined by 
the REGISTER option. The I and J limits of the desired window are 
determined by the subroutine LIMITS. Then the image coordinates 
are calculated for each I, J present iri the \vindbw and a 3 x 3 cross 
is generated at the center of each cell. 

The INSERT option utilizes the polygon routines to aggregrate 
LANDSAT resolution data to the K-cell level. At present INSERT 
will accommodate the aggregation of ground cover classification 
only, but it may be easily expanded. 

Finally the STOP option ceases all processing. 
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4.9.U Comtnon Areas 


a. VIDW 

1 . NROW - First row of windov/. 

2. NROWS - Number af rows in v/indow. 

3. NCOL - First column of window. 

4. NCOLS - Number of columns in window. 

5. II - Minimum I value in window. 

6. 12 “ Maximum I value in window. 

7. J1 “ Minimum J value in window- 

8. 02 “ Maximum J value in window. 

b. AFN 

1. V (3) - REAL*4, AFYNE coefficients, image 
to LAT, LON, first row. 

2. VV (3) - REALH, AFYNE coefficients, image 
to LAT, LON, second row, 

c. BFN 

1. Z (3)- REAL*4, AFYNE coefficients, LAT, 

LON to image, first row. . 

2. II (3) - REAL*4, AFYNE coefficients, LAT, 

LON to image, second row. 

4. 9. 1.2 Variables 

a, REGIST - Flag equals 1 if image has been reg- 
istered, equals 0 otherwise. 

4.9.2 AFYNE 

Subroutine AFYNE allows the user to identify ground control 
points (GCP's) through the Image 100 cursor. The user is prompted 
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to enter the latitude and longitude of each ground control point. 
The subroutine then performs a least squares fit to the ground 
control points to determine the best affine transformation relating 
the GCP's to latitude and longitude. The affine transformation is 
defined as: 

LAT = A^I + 

LONG = Agl + + Cg 

where 

LAT is the latitude of a particular GCP 
LONG is the longitude of a particular GCP 
I is the row index of the GCP 
d is the column index of the GCP 
Given N GCP's, define the following quantities j 




Then the coefficients of the affine transformation may be solved as 
follows; 

' '' \at “ 

long = A C^ONG-^ C^ONG 

AFYNE uses subroutine MATINV to perform the matrix inversion. 

4. 9. 2.1 Argument List 
None 

4.9. 2.2 Common Area 

a. AFN “ See 4.9.1. 1 

4. 9. 2. 3 Variables 

a. V(3) - REAL^4i Temporary storage for vectors A 
LAT and A LONG 

b. VV(3) - REAL*4, Affine coefficients for lati-. 
tude transformation 

c. VVV(3) - REAL*4, Affine coefficients for longi- 
. tude transformation 

d. AA(20, 3) - REAL*4, Storage for matrix A 

e. BB(3,3) - REAL*4, Storage for matrix {AA)“^ 
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f. CC{3,3) - REAL*4, Storage for matrix (AA) 

g, DD(3,3) - REAL*4, Not used 

h, ZI(20) “ REAL*4, Storage for GCP row indices 

i. 2t3(20) - REAL*4, Storage for GCP column indices 

j. ZII(20) - REAL*4, Storage for GCP latitudes 

k, 2JJ(20) - REAL*4, Storage for GCP longitudes 

4.9.3 GRID 

Subroutine GRID generates a WMO grid overlay on a theme 
plane of the Image- 100. GRID calls subroutine LIMITS to determine 
the maximum and minimum I and J coordinates grid window contained 
within the image window. Note that since the image window and grid 
v/indow are skewed, not every I,J cell in the grid window is contained 
in the image window. Hov/ever, the image window is wholly contained 
within the grid window. 

Next a loop is entered in which each I, J coordinate is 
tested to determine if it is contained within the image window. If 
it is, a 3 X 3 cross centered on the I,J coordinate is generated on 
the desired theme plain, 

4. 9. 3.1 Argument List 

None 

4.9. 3.2 Common Areas 

a. WDW - See 4. 9. 1.1 

4. 9. 3. 3 Variables . 

a. THEME - Output theme number. 

b. LINl - First Tine of cross. 

c. LIN2 - Last line of cross. • 
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d. C0L1 - First column of cross. 

e. C0L2 - Last column of cross. 

4.9.4 AGGR 

Subroutine AGGR aggregates LANDSAT classification data to 
the K cell level and inserts it into the data base. First it calls 
limits to get the image vnndow coordinates (row, column) in the 
corresponding grid windov/ coordinates (1,0). It then enters a loop 
which processes each I,J in the grid window. First it determines 
the Intersection of the I,J cell and the image vn'ndow. If the cell 
is contained in the watershed and is partially or completely con- 
tained v/ithin the image vnndow, the cell vertices are passed to the 
polygon routines BORDER (Section 3.8.3), SORT (Section 3.8.4) and 
FILL200. These determine the interior points of the cell and 
return a histogram of the polygon data contained within the cell 
along with the total population of the cell. This information is 
converted to percentage of ground cover, encoded in ASCII and 
inserted in the corresponding record of the archive file. 

4.9. 4.1 Argument List 

None 

4. 9.4.2 Common Areas 

a. WDW - See 4.9.1. 1 

b. KCELL 

1. K - K-cell number. 

2. KHIST (8,4) - Polygon data histograms. 

3. KNUM (4) - K-cell populations. 

c. VTX 

1. POINT (2,100,2) - K-cell border points. 

2. NPT - Number of border points. 
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3. VERTEX (2,4) - K-cell vertices. 

4. NVTX - Number of vertices. 

5. LINK (5) - Pointers used by SORT. 

d. INDEX - See 4,5.2 

# 

4.9. 4.3 Vari ables 

a. KI (4,4) - REAL*4, Table for calculation of K- 
cell vertices. 

b. KJ (4,4) - REAL*4, Table for calculation of K- 
cell vertices. 

c. PCT ~ REAL*4, Ground cover percentage. 

d. IPCT (8) - Ground cover percentage. 

e. ADAT (8) - Ground cover (ASCII). 

f. NSPACE - Position of ground cover field in 
archive record. 

g. NCHAR - Length of ground cover field in archive 
record. 

4.9.5 LIMITS 

Subroutine LIMITS prompts the user for the desired image 
window coordinates and calculates the grid window (I,J) which 
completely contains the image window. This is accomplished by 
calling IJREG (Section 4.7,5) to convert the image coordinates of 
the four Image corners to their corresponding I,J coordinates. The 
maximum and minimum I and d values obtained by these four trans- 
formations define the bounds of the grid window. 
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4.9. 5.1 Argument List 
None 

4. 9.5. 2 Common Areas 

a. WDW - See 4. 9. 1.1 

4.9.5.S Variables 

a. IMIN - REAL*4s Minimum I value. 

b. IMAX - REAL*4, Maximum I value. 

c. JMIN - REAL*4, Minimum 0 value. 

d. JMAX - REAL*4, Maximum 0 value. 

4-9.6 FLIP 

Subroutine FLIP accepts six AFYNE transformation coeffi- 
cients and inverts them to define the reverse transformation. 

4.9. 6.1 Argument List 

. a. V (3) - REAL*4, Input coefficients, first row. 

b. VV (3) - REAL*4, Input coefficients, second 
row. 

c. Z (3) - REAL*4, Inverted coefficients, first 
row. 

d. ZZ (3) - REAL*4, Inverted coefficients, second 
row. 

4.9.7 XYRE6 . 

Subroutine XYREG accepts the grid coordinates (I,J) of a 
pixel and converts them to image coordinates (row, column). First 
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the 1,0 coordinates are converted to latitude and longitude which 
is then converted to row and column by an AFYNE transformation. 

4.9.7. 1 Argument List 

a. XI - REAL*4, I coordinates. 

b. Xd - REAL*4, 0 coordinates, 

c. X - REAL*4, Calculated row coordinate. 

d. Y - REAL*4, Calculated column coordinate. 

4.9.7. 2 Common Areas 

a. BFN - See 4. 9.1.1 

4. 9.7. 3 Vari abl es 

a. XLAT - REAL*4, Calculated latitude. 

b. XLON - REAL*4, Calculated longitude. 

4.9.8 FILL 200 

Subroutine FILL 200 is a functional equivalent of FILLIN as 
described in Section 3.8.5. They differ only in that FILL 200 
calls INS 200 which aggregates theme data rather than INSERT which 
builds an output buffer to be written to a theme. 

4.9.9 INS200 

Subroutine INS200 is called by FILL200 to aggregate a histogram 
of the K cell polygon data. It accepts a start column, end column 
and a row number and returns a histogram of the pixels contained with- 
in those limits. 


/I .9.T0 mjim 

Subroutine MATINV uses a gaussian elimination with pivoting 
procedure to perform a matrix inversion. 

4.9.10.1 Argument List 

a. N - Order of matrix (maximum of three) 

b. A(3j3) “ REAL*4, On entry, matrix to be inverted 

on return, matrix inverse 

c. ISIN6 - Matrix return flag; 

0 - non-singular 

1 - singular 

4.9.10.2 Common Areas 
None 

4.9.10.3 Variables 

a. LIST(3) - Row interchange record 

b, DETR - REAL*4, Determinant of matrix 
4.9.11 User's Guide 

ERTS200 is initiated by the MCR command RUN ERTS200$’. ‘ The 
user will be requested to supply the following information. 
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PROMPT 
OPTION? > 

for REGISTER option 
IMAGE X, Y? > 

LAT, LON? > 

for OVERLAY option 
OUTPUT THEME? > 
for OVERLAY and INSERT options 
FIRST LINE? > 

NUMBER OF LINES? > 

FIRST COLUMN? > 

NUMBER OF COLUMNS? > 


RESPONSE 

Register, Overlay, 
Insert or Stop 


Enter column. Row of G.C.P. 
or position cursor and press 
C.R.. Enter X to exit 

Enter Latitude, Longitude of 
G.C.P. (2F12.4) 


Integer (1-8) 

Positive integer 
Positive integer 
Positive integer 
Positive integer 
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appendix b 


The 1980 Hydrologic Forecast situation: Where the major 
deficiencies v/ill exist and how they may be improved. 


SUMMARY 

In the 1980' s the demand for water will have risen considerably 
over the present levels in the conterminous United States. This demand 
will be felt most extensively in the urban areas of the v/estern states. 

How will this demand be met by the 1980 state-of-the-art technology, and 
whfere are the likely deficiencies in the forecasting procedures going to 
occur? As can be best inferred from informative sources active in water 
resource management, the water forecasting procedure will rely heavily on 
data relay by ground, aircraft or satellite based transmission devices 
for more timely and reliable point source measurements of the naturally 
occurring phenomena related to river discharge. Localized automatic data 
receiving and processing centers will be in widespread use by such agencies 
as USGS, Department of Agriculture and others, for rapid centralized 
interpretation of conditions not only in one basin, but on the regional 
level in many parts of the country, thus providing a larger data base 
from which to more accurately forecast local conditions. 

Although we may expect greater use and refinement of ground based 
telemetered data from point source measurements, a significant barrier to 
reduction of the forecast error will still remain. The barrier will be the 
obtaining of timely data on areal distributions of such water budget vari- 
ables as soil moisture, evapotranspiration and snow water equivalence. 
Addendant meteorologic surrogate information including wind speed, net 
radiation, humidity, temperature and other parameters can presently be 


measured either directly or indirectly, but the relationship of their 

aerial distribution to the real v/ater balance of a basin is yet to be 

defined and applied to the actual basin-wide forecasting activity on an 

* 

operational basis. 

In brief, 1980 forecasting procedures will rely on technologically 
advanced methods of identifying, more accurately and rapidly, the hydrologic 
conditions at sample points throughout the basin in question. However, 
because the limitations to reduction in the forecast error beyond this 
level are inherent in the limitations of the point source sampling pro- 
cedure, the major contributions to forecast improvement by 1980 will be 
those techniques which allow interactive operations and employ direct or 
surrogate measurements of the areal extent of the actual phenomena in 
question. 


INTRODUCTION 

The attempt of this paper is to relate the forecast deficiencies 
in the T98G’s. This subject implies many facets, each of which could 
occupy the bulk of the report alone. Within the time allotted, only the 
more important topics are discussed, each of which builds upon the 
predecessor to provide a foundation for the projections. What follows 
then, is a discussion of current forecast techniques, the current forecast 
errors, and future forecast techniques and expected errors. Prerequisite . 
to an understanding of the rationale behind a hydrologic forecast is an 
understanding of the hydrologic cycle: the process which defines the flow 
of water in the earth and atmosphere. 

THE CYCLE 

In the hydrologic cycle, water evaporates from the oceans and the 
land and becomes a part of the atmosphere. The evaporated moisture is 
lifted and carried in the atmoshpere until it precipitates to the earth, 
either on land or in the oceans. Precipitated water may be intercepted 
or transpired by plants, may run over the ground surface and into streams 
and oceans, or may infiltrate into the ground. Much of the intercepted 
and transpired water and some of the surface runoff returns to the air 
through evaporation and transpiration. The infiltrated vvater may percolate 
downward to be temporarily stored as groundwater which later flows out of 
rocks as springs, or seeps into streams as runoff to oceans, or evaporates 
into the atmosphere to complete the cycle. Thus, the flow of water through 
the hydrologic cycle undergoes various complicated processes of evaporation, 
precipitation, interception, traYispi rati on, infiltration, percolation, storage 
and runoff. Figure B-1 illustrates this flow. 
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FIGURE B-1 

Diagrammatic representation of the hydrologic cycle. (Adapted from ASCE 
Hydrology Handbook, 1949). Source: Walton, w. C. Ground Water Resource 
Evaluations, McGraw-Hill, Inc., N. Y. p. 4. 



FIGURE M 

Diagrammatic representation of the hydrologic cycle. (Adapted from ASCE 
Hydrology Handbook, 1949), Source: Walton. W. C. Ground Water Resource 
Evaluations, McGraw-Hill , Inc., N. Y, p. 4. 


The amounts of evaporation, precipitation, runoff and other 
hydrologic cycle quantities are not evenly distributed on the earth, 
either geographically or temporally. In the conterminous United States, 

a 

annual rainfall averages 1,430 cubic miles; evaporation is about 1,000 
cubic miles; and about 40 cubic miles of water is discharged directly into 
the oceans from groundwater reservoirs. Several times 40 cubic miles of 


water passes through inland groundwater reservoirs and reaches stream 

y 

channels to be discharged to the ocean via surface streams. 


CURRENT FORECASTS 

In the United States, tv/O general forecasts of riinoff are used 
depending on the requirements of the user. These are either forecasts 
of short term runoff Including hourly, daily and seasonal predictions for flood 
warning or hydropower applications, or forecasts of annual runoff for 
recreation irrigation, hydropower, water supply and other uses. These 
forecasts may or may not depend on snow melt information depending on 
the geographic area in which the forecast is made. 


CURRENT FORECAST PROCEDURES 

Current forecasting procedures mostly utilize a wide variety 
of point source measurements of the phenomeraa (as was illustrated in 
Figure B“l,and combine these data with historical data in a regression 
equation to generate a forecast. A variety of computer programs have 
been developed to more accurately predict runoff by simulating the 
hydrologic cycle. However, the accuracy of the computer generated 
forecast is limited by the accuracy and representativeness of the input 
point source measurements. A subsequent discussion of modeling procedures 
will identify how the components of the hydrologic cycle are assembled 
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for forecast purposes. More appropriate at present is the evaluation 
of point source measurement limitations. 

Illustrative of the limiting effect of point source measurements 
is the effect of an increasing number of raingauges on actual reduction 
in average error of measurement. In the following network chart (Figure B-2) 
it can be demonstrated that for any particular basin of known storm rainfall 
amounts and average annual precipitation, a non-linear progression of the 
increases of gauges (point source measurements) is required to bring about 
a uniform reduction in error. In other words, the addition of more point 
source measurements reaches a point of diminishing returns with respect 
to the decrease in error related. 

ERRORS IN FORECASTING 

The above point becomes salient in consideration of the fact that 

the west wide normal error in forecasting is on the order of 18 percent 

2 / 

ranging from 7 to 40 percent. The remaining national forecast error is 
less than this figure with less variation. As will be related, the 1980 
water allocation demand will require significant improvement in the current 
forecast error particularly in the southwestern states. Particular error 
distributions for various western regions are shown in Table 1 to pinpoint 
the geographic distribution. Of interest in this distribution is the 
fact that the areas of higher forecast errors are in general expected to 
receive the major Influx of future population expansion. 

Another factor to consider in the current forecast procedures 
is that of the range and distribution of error in measurement of the in- 
dividual variables of the water budget. Of these variables the majority 
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DRAINAGE AREA (A) IN SQUARE MmCS 



Network chart for estimating the error in watershed average rainfall amounts. 
Source: Soil Conservation Service "Hydrology” , Section 4 of National Engineering 
Handbook, 1969, p.4-20. 



of water budget calculations over the v^ho^e United States suggests that 

evapotranspiration and soil moisture are the two major unknowns in the 

general runoff forecast. According to a credible source: 

"Host programs for basic data cover precipitation, stream- 

flow, evaportanspiration, ground water occurrence and 

other phases of the water cycle we already know about. 

The recommendations generally made for additional water 

data include very little pertaining to infiltration, 

soil moisture, and evapotranspiration which constitute 

the soil water phases of the water cycle. So little 

is actually known about these phases that even the 

listing of the national needs for additional data is 

a formidable task as is determining how their lack 

3/ 

effects the national economy." 

Particular interest might be centered on evapotranspiration 
because of its often dominant and unpredictable effect on the water 
budget. Commonly, evapotranspiration is estimated to amount to about 
33 percent of runoff by mere rule of thumb because of a lack of field 
data and procedures by which more accurate measurements can be made. 

(This figure may range up to 60 percent in the arid southwestern United 

i/ 

States.) 

Field calculations of evapotranspiration generally rely upon 
extrapolation from point source measurements of evaporation, with corrections 
made to account for water losses due to transpiration from vegetation. More 
direct point source measurement of evapotranspiration is accomplished by 
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Forecast Error Distribution 


Region 


Av.. Error*% Sub-Region Av. Error* (%) 


California South Pacific 

10.0 

Tulare 

10.0 



San Jaoquin River 

10.0 



Delta Central Sierra 
Sacramento 

10.0 

Columbia North Pacific 

10.2 

Clark Fork Kootenai 




Spokane 


"Upper Columbia" 

7.7 

Upper Columbia 

7.7 


Yakima 

11.2 



Upper Snake 

17.2 

"Snake" 

17.2 

Central Snake 

21.0 

"Lower Columbia" 

16.6 . 

Mid Columbia 

16.6 



Lower Columbia 
Puget Sound 

12 

North Pacific Coastal 

18.4 

Coastal 

21 

Great Basin 

22.9 

Bear River 

21 



Great Salt Lake 

10 

• 


Sevier Lake 
Central Lakoutian 
Humbolt River 

40 

Colorado 

26 

Upper Colorado 

14 



Green River 

17 



San Juan Colorado 

17 



Little Colorado 

27 



Salt Verde-Gila 

37.5 

Rio Grande 

29.1 

Upper Rio Grande 
Upper Pecos 

15.2 

Arkansas 

37.1 


37.1 

Missouri 

18.1 

Upper Missouri 
Yellowstone 

17.1 



Platte Nebraska 

19 

* Average Error is that error 

deri ved from 

the most recent 10 years record 


for the April 1 forecast. Where recent data was unavailable, error data 
was taken from less recent and more extensive periods of time. 


Source: Unpublished West-wide Summary of SGS Forecast Error. SCS, SpokanCj 

Washington. 

TABLE - B-1 

Forecast Error Distribution According to Geographic Location 
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use of a lysimeter, but due to the expense of this device, it is used 
only in a few of the more well funded research stations of the Department 
of Agriculture. 

In actual basins which are hydrological ly better defined in 
terms of having more extensive gauges, uniformity of climatology, greater 
length of data recorded, etc., evapotranspi ration may be derived through 
a water balance accounting. Using this procedure, the net losses in the 
hydrologic cycle (which are otherwise unaccounted for) are assigned to 
evapotranspi ration. This subtractive process is limited by the accuracy 
of other measurements in the water cycle. A final method of generating 
evapotranspi rati on , used singularly or (more often) in conjunction with 
the other methods, entails the measurement of humidity, wind speed and 
temperature in. an energy balance accounting to derive the evapotranspi rati on 
data. This method, used alone is rarely accurate because it fails to take 
into account available soil raositure in the basin and other unique basin 
characteristics which contribute to the actual evapotranspi rati on. 

Like evapotranspi rati on, soil moisture may be derived from 
point source measurements. Soil moisture may also be computed on the basis 
of other inputs to the forecast. Its role in the total water budget is 
generally less dominant than evapotranspi rati on. Because the measurement 
of soil moisture is obtained by logic similar to that used in evapotrans- 
plration. The discussion of measurement techniques will be bypassed here. 
Suffice it to state, however, that soil moisture is closer to being ac- 
curately quantified than evapotranspi rati on because of its more direct 
relationship to observable phenomena including soil type and extent. 
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Snow water equivalence 'data is currently derived by a combination 
of point source measurements of snow thickness and density which are mul- 
tiplied by areal extent measurements to derive total water content of the 
snowpack. The point source measurements of snow density are made either 
by ground based surveys or low flying aircraft using transmitted gamma 
radiation measurements from ground based recording stations. Areal extent 
measurements, in themselves, are well defined and accurate relative to 
the snow depth/density measurements. Hence, the major problem posed by 
determination of total snow water equivalence is limited largely by the 
accuracy of snow depth/density measurements over a given areal extent of 
snow. The measurement of snow water equivalence applies mostly to the 
mountainous western basins in which snow derived runoff comprises a sub- 
stantial percentage of the total precipitation. 

FORECAST RESEARCH ACTIVITY 

A brief look at presently funded research and operational activity 
of the larger government organizations suggests what is being done to reduce 
the forecast errors. Accordingly, the function and research activity of each 
of the major agencies concerned with hydrologic forecasts is capsulized in 
Table B-2. 

Within and among these agencies the vast majority of the nation’s 
larger water courses are currently under some management scheme. Implied 
by the research activity of these agencies is the fact that they have an 
expressed interest in improvement of their current forecast operations. 

In this effort, the USGS is extending its stream flow and precipitation 
gauge data telemetering activity throughout the major watersheds. Soil 
Conservation Service is active in the installation of telemetered snow pillow 
data for uncovering more point source measurements of snow depth and water 
equivalents. 
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Agency 

Primary Forecast 
Objective 

Hydrologic Research 
Activity Allied to 
Forecasting 

Bureau of 
Reclamation 

Multipurpose reservoir 
operations 

Weather modification 
gauge telemetry 

U,S. Army Corps 
of Engineers 

Flood Control 

Gauge telemetry and data 
centralization snov/ hydrology 

U.S. Department of 
Agriculture (SCS) 

Water supply and 
Irrigation 

Gauge telemetry- 
Snow hydrology 

National 
Weather Service 

Flood Warning 
Weather Hazard Warning • 

Gauge telemetry 

U.S. Geological 
Survey 

Supports other agencies 
by providing hydrologic 
data, etc. 

Gauge telemetry and gauge 
measuring improvement 

State Agencies 

Multipurpose 

Basin studies for 
specific application 


"S 


Source: Personal Communication as per reference 6. y 
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TABLE B-2 


■i 


j 


i 


Major Agency Research Activity Allied to Water Forecasting. 


National Weather Service is engaged in automation of a real time data 
network for flood warning across the United States, and is involved in the 
use of these relay devices for a v/ide variety of data recorded. Bureau of 
Reclamation, although its greatest hydrologic research effort is to study 
weather modification, has recently begun to invest considerably in automation 
of its data recording instruments. Uniform dollar figures are hard to assign 
to the data telemetering activities of the various agencies because the bud- 
geting of categories of each agency vary widely. A coordinated controlled 
program of data telemetry is of enough concern to all of the above agencies 
that they are operating together under the coordinating efforts of the Army 
Corps of Engineers. This effort is identified as the National Hydrometeorolo- 
gical Reporting Network (Hydromet) and is in various stages of development 

6 / 

depending on where in the country one looks for the facts. The project 
is intended to be operational by 1975 in the Pacific Northwest where efforts 
are most concentrated but nationally Hydromet is far from complete at present. 
From the persons contacted, however, 1980 is not a premature date to expect 
a nearly operational system in most of the major river basins of the con- 
terminous United States. The methods by which these and other hydrologic data 
are currently applied to the more well researched basins are explicit in the 
discussion of forecast modeling activity. 

MODELING APPLICATIONS OF FORECASTING ACTIVITY 

Computer synthesis of forecast activity is a relatively new art, 
and long term records of operation are not common. Essentially, three major 
systems are in operation and the general trend reflects progressive advance- 
ment from one system to the other with increasing sophistication of the fore- 
casting agency. 


«3.i®aoptiGiBiLrrY 
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These three systems are' defined as. Parametric (using statistical 
regression analyses). Analytic (using generalized indices of the water budget 
variables), and Simulation Systems, which attempt to incorporate each or as 
many individual hydrologic related processes in the basin as possible. The 
outputs of these systems are designed to produce either an event centered 
forecast (e.g., flood warning potential) or a continuous forecast (for such 
applications as seasonal or annual water supply). An example of a more 
developed and widely recognized model is that of the SSARR model, developed 
by the U.S. Army Corps of Engineers (Figure. B-3 depicts the model algorithm). 
Focus on the procedures used by this model will assist in providing the link 
between satellite sensor research, capability and operational forecasting 
applications in the 1980 's. The rate of information being currently generated 
by research in this area suggests, however., that considerable alteration of 
the Inputs to the forecast variables, and probably alteration of the model 
algorithm will have occurred by the projected period. 

Computerized model applications to future forecasting methodology 
is best developed through a brief review of the SSARR model operation. The 
SSARR model is a mathematical hydrologic model of a river basin system 
throughout which streamflow (runoff) can be synthesized by evaluating snow- 
melt and rainfall. This model divides the precipitation runoff process 
into three major categories; runoff, soil moisture, and evapotranspiration. 

Runoff is determined by the weighted average precipitation over 
the entire watershed by an empirically derived relationship of 
soil moisture versus runoff percent. The soil moisture index, is often 
termed an intermediate computer variable, and unlike the runoff factor. 
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FIGURE B-3: SSARR Model Algorithm for streamflow forecasting, 

















It is not a direct input to this model. Instead, the soil moisture index 
is derived indirectly through an accounting of the precipitation, runoff 
and total evapotranspiration data. Evapotranspiration is a direct input 
variable. It is determined by a weighting and statistical manipulation 
of point source data. The techniques of deriving these point source data 
are essentially those described In a previous section. 

The total generated runoff is divided into its three components: 
baseflow, surface flow, and subsurface flow .based on pre-established (field 
data derived) relationships (i.e. baseflow infiltration index vs. surface 
input). Each of the components are then routed through a series of linear 
reservoirs and summed to yield the total hydrograph. Snow water equivalence 
data for this model incorporates the measure of snowline elevation, temperature 
measurements, snow extent, snowpack characteristics, snow type, and thickness 
In its current operation. 

Several other models exist, but their delineation would not serve 
the objectives of this report. Because of the inherent multiplying effect 
to be realized by improvements in the modeling of water resources activity, 
the most effective advantages to future forecasting will be realized by 
efforts which adjust remote sensing data to the models themselves. 

The potential attributes of similar models are significant since 
they can permit development of explicit descriptions of various hydrological 
processes that can now or may, in the future, be directly observable by re- 
mote sensing. This capability provides the ability for the forecast models 
. to grow as our knowledge and accuracy of the uses of remote sensing grow. 

Because of the lag between research and specified field applications 
found to be present in many of these agencies, it is felt that prediction 
of the 1980 field forecasting situation, based on present research, is not 
as unreliable as one might expect. (Evidence for the 1980 situation is 
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gathered largely from personal communication with the above mentioned 
forecast agencies in conjunction with past work on the water resources 
case study contribution to the on-going cost benefit contract.) 

By 1900, the research-generated forecasting techniques will be 
a good deal more applied than they are at the present time. The difference 
or advancement, however, will incorporate more of a change in extent of the 
present day research technology rather than introduction of unique measure- 
ment techniques. Specifically, the use of telemetry and automatic data 
processing tecnniques will permit near real time transmission of data 
from most point source measurements in the basin to a centralized control 
station. From this station the incoming measurements will be transferred 
to particular computerized hydrologic models for the basin. In combining 
these data with historic records, the models will enable calculation of 
the water budget on a real time basis. On a larger scale, these data can 
be retransmitted from the basin center or transmitted directly to the 
central agency (for example, a central hydromet facility) for regional 
analysis. At this larger level, meteorologic information will be of 
significant value to the interpretation and prediction of regional hydro- 
logic conditions. 

The shortcomings of these forecasting advances vrill still be 
found in the problem of assessing the areal distribution of the water 
budget components on the basis of point source measurements. The ac- 
curacy of the forecast will still be limited by the accuracy of assess- 
ment of areal distribution of evapotranspiration and soil moisture in 
particular. Point source measurements of snow density and depth will 
likewise limit snow water derived runoff forecasts In the western mountainous 
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areas 


As is implied by these projections, improvement In the assessment 

9 

of areal extent of the hydrologic phenomena will become increasingly dependent 
upon direct areal extent measurement of the phenomena rather than upon point 
source measurements. 

PROJECTED FORECASTING TECHNIQUES: APPLICATION OF REMOTE SENSING FOR ASSESSING 
AREAL EXTENT OF PHENOMENA 

The point source measurement technique employs statistical analysis 
which Is only as good as the sampling netv/ork a'nd measurement accuracy at the 
sampling sites. The alternative technique of direct areal extent measurement 
using aircraft or satellite, however, is yet to be defined In terms of its 
accuracy and availability to the watershed managers. For example, the state 
of the art of aerial remote sensing of evapotranspiration assessment is cur- 
rently possible only through knowledge of hydrometeorologic conditions in 
conjunction with vegetal vigor changes, neither of which have been correlated 
for the purpose of pinpointing their relationship to actual evapotranspiration. 
Aerial remote sensing by 1980 will, hopefully, be able to provide the kind of 
detailed information which may permit application of hydro-climatic data for 
a specific basin which is itself accurately identified with respect to vege- 
tation and soiU It is the refinement of the sensing system in conjunction 
with more accurate measurement of other hydrologic parameters which will 
permit accurate identification of evapotranspiration rates and extent. To 
date, however, such results are not demonstrated because of the concomitant 
lack of defined sensor capabilities and research linking those capabilities 
to the actual forecast procedure on a real time basis. 

Parallel to this situation is the situation for soil moisture 
and snow water equivalence approximation using areal extent measurements. 


Soil moisture is somewhat quantifiable in those areas of little or no 
vegetative cover presently identified as containing greater or less than 
20 percent soil moisture, on the basis of the soil reflectance and knoW” 
ledge of the soil type. Much finer discrimination v/ill accrue with the 
use of better sensors, more extensive delineation of soil types, and the 
added information concerning vegetal vigor relationships to soil moisture. 

As indicated, these parameters, governing soil moisture measurement, are 
currently under investigation. It is expected by 1980, that the assessment 
of the areal distribution of soil moisture will be refined. 

Snow v/ater equivalent, like evapotranspiration, is a highly per- 
plexing phenomena to assess over any given area. Unlike evapotranspiration, 
however, snow water equivalence is closer to being predictable by 1980. 

This is so because some of the surrogate parameters which define snow water 
equivalent are currently being identified, and incentive for progress in this 
discipline is considerable (due in part, to the economic impact of improving 
the snow water forecast). Already demonstrated by ERTS investigators is the 
fact that areal extent of snowpack is directly observable to a level of ac- 

II 

curacy equalling or exceeding conventional procedures. ‘ Likewise, snow 
brightness as an indicator of ripeness or age which may suggest snow density 
and/or areas of snow accumulation is currently being defined by research. 

When these data are perfected and aligned to temperature measurements, hydrologists 
may have a measure of areal distribution of snow density and melt potential. 
Aligning these data with the historical record will aid 1n prediction of total 
snow water releases during the melt season. 

A matrix which capsulizes these aspects of the current and projected 
1980 hydrologic forecast procedures is shown in Table B-3. Another method of 
stating the situation is through a diagram of the water resource management 
Information system Table B-4. This diagram explains only what the relation- 


Table B-3 Current and Projected Forecasting Techniques. 


Current Technique 


Snow Water Equivalent -a Point source raeasurement either 

surveyed on foot or by aircraft. 
(Most common is densitometry 
measurement involving the 
weighing of a given volume of 
snow either with tubular coring 
devices or with snow pressure 
measuring devices commonly 
identified as snow pillows.) Low 
flying ari craft are used to both 
read snow depth markers and in 
some cases record radio isotope 
point source measurements. 

Soil Moisture 0 Point source measurements using 

electrical resistivity or 
manual sampling of soil involving 
assessment of weight difference 
between natural soil sample and 
dried sample. 

e Aerial remote sensing which 
permits distinction between 
saturated and dry soils in un- 
vegetated areas . 


Evapotranspi ration 



e Point source gauge measurement 
using correlation between gauge 
and field conditions. Data 
collected by field surveys. 

® Other measures, in areas where 
point source measurements are 
impractical, involve estimation 
of evapotranspi rati on by vrorking 
back through water budget, and 
assigning the unaccounted water 
losses to evapotranspi rati on. 

9 Another technique is to cal- 
culate evapotranspi rati on on 
the basis of field derived 
temperature humidity and wind 
speed as limited by the available 
soil moisture. 


Projected Technique 


9 Satellite or ground relay of telemetered 
radioisotope point measurements of 
snow water content in conjunction with 
satellite or ari craft monitoring of 
snow depth via markers. 

9 Continual monitoring of albedo changes 
as an indication of new snow accumulation 
through the season. (Direct snow water 
equivalence data, not as yet available 
through aerial or satellite based systems 
but surrogate information will provide 
close approximation.) 


& In unvegetated areas, changes in 
reflectance of a given soil can be 
sensed and resolved to a much finer 
degree which permits finer soil moisture 
dsi crimination. 

9 In vegetated areas, infrared remote 
sensing of changes in vegetal vigor 
identifies soil moisture, given index 
plots in which the relationships 
between vegetation, soil moisture 
and salinity types is defined. 

9 Extensive telemetered network of 
point source measurements as 
described in current techniques. 

9 Expansion and refinement of equations 
which calculate evapotranspi rati on 
as also described in current 
techniques. (Accurate direct 
surrogate measures of areal extent 
not yet devised.) 
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HYDROMETEOROLOGICAL SATELLITE ASSISTED WATER MAMAGEMENT SYSTEMS 
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ships between the sources of information (collection vehicles) and the 
ultimate application of the forecast is. 

What the diagram (Table B-4) suggests is extremely promising: what 
must be done to demonstrate the promise is considerably arduous. We need 
to: 

1) identify the relationships of forecast variable to forecast 
particular emphasis on the three previously stated factors s 
snow water equivalence, soil moisture, and evapotranspi ration. 

An activity such as a sensitivity analysis is necessary here. 

2) determine the relationship (sensitivity/dependency) of surrogate 
information, to the forecast variable, again with emphasis in the 
stated areas, 

3) apply the generated information of land to a variety of basins 
to test for size, terrain, climate vegetation and other effects. 

To an extent, this task is somewhat underway by virtue of the 
already defined remote sensing limitations allied to earlier 
sensor systems research. A brief review of the major limitation 
reported in the literature is appropriate here. 

Paramount to improvement of forecast accuracy by using areal 
remote sensing techniques is the question of sensor limitation. Pertinent 
to this discussion, cloud cover, forest cover, sensor resolution, (parti- 
cularly spatial resolution) and frequency of coverage requirements comprise 
the limiting factors to monitoring of the variables previously mentioned. 


B-22 




CLOUD COVER 

In order for current sensors on the LANDSAT-l satellite (or for that 
matter* all other unclassified satellites) to record the reflectance in the 
visible and near infrared spectrum and radiation intensity at longer wave- 
lengths from the surface of the earth, the line-of-sight from the sensor to 
the surface must not be intercepted by obscuring clouds, fog, haze, smoke, 
and other pollutants. Furthermore, the clear zone on the space between 
the clouds must have a certain minimum horizontal extent in order that 
pattern recognition techniques may be utilized effectively. There is a 
continuum of opacity or transparency ranging from thin clouds to clear sky. 
There is a corresponding continuum of the quality of sensor observations. 
Clouds superimpose returns of their own, having the effect of attenuating 
and scattering returns from the earth's surface. These effects produce 
blurring and reducing of image contrast. However, it is possible to obtain 
useful information from a satellite even though a weather situation might 
be reporting overcast conditions. What contributes to the discrimination 
of cloud cover interference data from snow cover is that cloud appearance 
on ERTS or high altitude imagery is diagnostically unique to snow as a result 
of the difference in the processes which form both. Clouds vary in opacity 
and relative to snow are independent of the land forms which they overlie. 
Because of this fact, in those basins in which land forms produce less than 
typically unique appearance to snow forms, it would be somewhat more difficult 
to differentiate snow from clouds despite the availability of data on cloud 
interference for a given area. 

Based on the above discussion, and in conjunction with demonstrated 
LANDSAT-1 research results, cloud cover is found to Impose major limitations 

•in the Pacific Northwest basins which drain directly to the Pacific Ocean. 

For reference purposes, a N-S boundary of this area would intersect Mount 


Olympia and trend south to the Sacramento River Basin in Northern California. 

From that latitude, the boundary line would trend west to the Pacific Ocean. 

Generally speaking, other areas of the United States are far less 
obstructed by cloud cover, however, local conditions might deviate from this 
impression considerably. It remains to be demonstrated by future satellite 
or high altitude aircraft remote sensing research. 

FOREST COVER LIMITATIONS ' 

Forest cover poses another problem in that the present sensors 
cannot “look" through dense canopy covers of coniferous species; hence, 
direct identification of soil moisture, snow cover, and snowline information 
is sharply limited in dense conifer forest. Although the identification of 
the relationship between canopy cover and soil moisture has not been fully 
researched, it is expected that work in this area will markedly reduce the 
current problems. Quantification of this effect is, at present, not possible 
because the density of canopy cover of the conifer forests is not yet known. However, 
LANDSAT - 1 experimenters have only recently generated information which may 
enable the future investigator to distinguish between changes in areal extent 
of vegetation and changes in vegetation biomass. This difference, obtained 
by contrasting bands 5 and 7 imagery, offers the potential to identify canopy 
extent and growth for forest stands of known density. The effect of this ca- 
pability is not only to allow calibration of areas in which forest cover will 
interfere with snow cover, but also to develop base information of soil moisture 
and transpiration in vegetated areas. (The distribution of conifers in the 
western basins is shown in Figure B-4.) Although this data is not infonaative 
by itself because of the lack of density of canopy infonaation, it does pro- 
vide a guide to the probable areas where interference could occur, pending 
further research. 
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FIGURE B-4: Forest Cover Regions In the Western United States 


SEWSQR RESOLUTION LIMITATIQHS 

Sensor resolution limitations for any given sensor vary with the 
kind of vehicle in which they are flown and the phenomena being measured. 

Because the focus of this report is an error occurrence in the future, only 
the optimum system sensor limitations will be discussed, to the exclusion 
Of all other systems which could be used to measure the phenomena. Current 
and planned weather, geological and other satellite systems as such, are 
not discussed here. Two limitations are implied by the term Sensor Limi- 
tations. These include spatial resolution, and spectral resolution limitations. 
SPATIAL RESOLUTION FACTORS 

Effective spatial resolution for the multi-spectral scanner sensor used 
in the LANDSAT satellite is on the order of -200 feet, which has proved 
sufficient in equaling or exceeding current aircraft in the delineation of 
snowline. Accordingly, areas of interest regarding snowmelt and soil moisture, 
are reported to be resolvable to -200 foot accuracy by the LANDSAT investigators. 
High altitude aircraft use of these sensors can narrow the resolution consider- 
ably depending on the altitude flown and the nature of the phenomena and other 
conditions under which it is observed. 

The question of what spatial resolution is optimum is, at present, 
open to debate. In flat lying terrain with an unobstructed field of view 
where boundary delineation can be made more precisely, higher resolution 
is of distinct advantage. Improvements in resolution are not necessarily 
an advantage, however, in areas where boundary lines are not definitive 
and/or where the field of view is partially obstructed by the previously 
discussed factors. Here, less spatial resolution can be a distinct ad- 
vantage in that the feature observed is interposed with the obstructions 
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to provide an integrated boundary line. This effect Is often reported 
in the ERTS and KOAA research concerning snov/ line, in which ERTS or NOAA 
data is compared to that of aircraf'* systems. By the next decade, however, 
spatial resolution will have the side effect of minimizing the limitations 
mentioned above if the assumption is made that variable resolution imagery 
will be obtainable for varying conditions. 

SPECTRAL RESOLUTION FACTORS 

The question of what is required by improved spectral resolution 
is at present dependent on the definition of current capabilities which have 
not been fully developed. As it now stands, spectral limitations on LANDSAT 
are due more to the lack of a mid range IR than to deficiencies in the 
operational sensors for the measurement of soil moisture and evapotranspiration 
as identified by vegetal vigor. However, this statement is tenous in light 
of recent results in band separation and contrasting used to discriminate 
vegetation growth types as discussed in the section of forest cover limitations 

Likewise, the capability to map snow density is suggested by some 
ERTS investigators to be just around the corner, but nothing other than a 
distinction between new snow and older snow or snow ‘'ripeness" conditions 
can be made at present. Snow density assessment is still in the pure research 
phase of development. 

FREQUENCY OF COVERAGE REQUIREMENTS 

The rate at which the forecasts are updated depends on a host of 
factors, and it is necessary to appreciate the variety of these factors in 
order to establish the effect of frequency requirements on aerial remote 
sensing potential. Such factors as the time of year of the forecast; the 
forecast type, the geographic location, the type of phenomena and the rate 
of change of the phenomena all enter into the assessment of frequency of 
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coverage requirements. In the case of snow hydrologic forecasting in 
the v/estern basins, the rate of snow melt during the February - July 
season can vary to the extent that coverage may be required from once 

every three weeks, to twice weekly, again depending upon basin latitude, 

♦ 

evaluation and other factors. 

A brief table showing the extremes in frequency of coverage and 
illustrating the variety present in the three hydrologic variables in 
question is shown below (Table B-5'. 


Table B-5 


Phenomena Critical Coverage Frequency Requirement* 

To Forecast Accuracy Minimum Maximum 



Pacific Northwest 

Southwestern 


basins annual fore- 

basins seasonal fore- 


cast prior to melt 

casts during melt 


season- February 

season- April 

Evapotranspi rati on 

Semi-monthly 

weekly 

Soil Moisture 

Semi-monthly 

weekly 

Total Snow Water Equivalent 
(as indicated by density depth 

Semi -monthly 

weekly 

and areal extent measurements) 




*Cover frequency determined on basis of present forecasting activity in the 
western U.S., using current forecast records and techniques. 


Source; Personal Communications as in Reference No. 8. 


Coverage Frequency Extremes for Critical Forecast Variables 


SOCIO-ECONOMIC FACTORS RELEVANT TO THE PROJECTED FORECAST ACTIVITY 


A few economic projections shed light on the location, kind and 
extent of need for more accurate forecasts which will exist in the 1980's. 
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By 1980, the United States population will have risen to 233 million 

persons. The rate of this increase will be greatest in the South Pacific 

western regions where the population will have doubled by that time. In. 

addition, demographic projections suggest that the largest total proportion 

of the population will be in the cities. To meet this growth rate, a 

twelvefold increase of steam electric generation and a 40% increase in 

irrigated agriculture will be realized by the end of the century. Other 

10 / 

specific water demand projections are available if needed. 

The effect of imposing increased water demands in a region which 
is already feeling the strain on its water resources thrusts a considerable 
responsibility on the shoulders of the water supply forecaster. Because 
of the fact that the increased demands are going to be felt in an arid area, 
the major tasks will be those of reducing, or at least accurately accounting 
for, evapotranspiration and soil moisture losses to a far more accurate extent 
than at present. Similarly, because of the dependency of the population on 
snow melt releases in the southwestern basins, considerably improved fore- 
casts of snow water equivalence will have to be developed to meet the demands 
of the future. 

CONCLUSION 

Population demography, forecast limitations using point source 
measurements, planned government sponsored hydrologic research basin 
computer modeling activity, and aerially derived remote sensing potential 
applications are suggestive of the greater needs of the responses to water 
forecasting in the coming decade. 

The specific demands to be placed on the forecaster will require 
development and implementation of improved aerial extent measurements of 
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evapotranspi ration, soil moisture and snow water equivalence. While 
the quantification of these data is not currently operational, all 
indications are that at least snow v/ater equivalence and soil moisture 
assessment techniques will be developed. Evapotranspi rati on, as judged 
from current research, is the least likely to be quanitifed by aerial 
remote sensing technology, by the 1980‘s. 


Interactive Computer Systems for Future Hydrological Application 

The application of Interactive computer systems to hydrology 
1s being accelerated by two rapidly advancing technologies, i.e., hydro- 
logical simulation models and remote sensing. Simulation models, as 
previously stated, provide a "real world" mathematical view of various 
hydrological processes, v/hile remote sensing offers an opportunity to 
monitor hydrological processes in a hereto/ore impossible manner. 
Application of these two technologies in an interactive system permits 
daily application of the most basic of scientific study approaches, i.e., 
" Observe , Predict , Observe ." 

NASA's Goddard Space Flight Center (6SFC) has under develop- 
ment an interactive information processing system which has been termed 
AOIPS (Atmospheric and Oceanic Information Processing' System). AOIPS 
will permit rapid processing and manipulation of remote sensor data, 
ground based observational data, historical data and will furthermore 
permit interactive operation of available hydrological simulation models 
using information derived from these sources. ‘ 

In order to exercise the capabilities inherent in the AOIPS 
and to provide an effective demonstration of its applications, we have 
defined a demonstration scenario which, while obviously incomplete, will 
permit potential users to sit at a console and operate on a set of real 
data in a real and complex basin. 
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Scenario Overvi ev^ 


The AOIPS hydrological demonstration scenario has been con- 
structed In the context of existing models and data sources. An effort 
has been made to choose a reasonably complex simulation model which 
might be expected to contain most of the elements of future models 
and all of the elements of less complex models. The models considered 
for the scenario include; 

(a) The SSARR Model of the Corps of Engineers (1964) 

(b) The Sacramento RFC model (1971) 

(c) The Stanford IV model (1966) 

(d) The HEC-1 Flood Hydrograph Model of the Corps of 
Engineers (1973) 

(e) The Urban Storm Water Runoff "Storm*' Model of the 
Corps of Engineers (1975) 

(f) The National Weather Service RFC Model Package (1972). 

While this list is by no means an exhaustive review of model techniques, 
it does contain a representative sample of "operational" models. 

The river forecast problem contains many of the elements which 
can be best served by remote sensing and interactive computer processing. 
The river forecast problem also includes information needs of urban flood 
forecasting and seasonal water runoff forecasting which are used for 
public disaster warning, hydroelectric pov^er management, and related irriga 
tion information needs. 

The National Weather Service River Forecast Model Package (1972) 
contains a generalized description of the techniques and programs which can 
be used to develop operational ‘river forecasts. 
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The general overview of the NWSRFS model package is presented 
in Figures B-5 and B-6. Figure B-5 outlines the soil moisture accounting 
subsystem while Figure B-6 covers the channel routing and flow routing 
procedures . 

Data requirements for the NWSRFS model package are dynamic, 
i.e., meteorological and hydrological data enter the system at short 
(3-6 hour) time intervals. Calculations of potential evapotranspi ration 
are prepared on a daily basis. 
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ROUTING TO PRODUCE FLOW AT A FLOWPOINT 



Figure B-6: Channel and Flov/ Routing Procedures. 


B-3B 










Soil Moisture Accounting 


The input parameters used in the NWRRFS and outlined in 
Figure B- 5 are listed belov/: 


a* 

K1 

b. 

A 

c. 

EPXM 

d. 

UZSN 

e. 

LZSN 

f. 

CB 

g- 

POWER 

h. 

CC 

i. 

K24L 

j. 

K3 

k. 

GAGEPE 

1. 

EHIGH 

m. 

ELOW 

n. 

NEP 

0. 

NDUR 

P- 

K24EL 

q- 

SRCl 


Ratio of average areal precipitation to the 
precipitation input 

Percent impervious area 

Maximum amount of interception storage (inches) 

Nominal upper zone storage. An index to the 
magnitude of upper zone capacity (inches) 

Nominal lower zone storage. An index to the 
magnitude of lower zone capacity (inches) 

Infiltration index (inches/hour) 

Exponent in infiltration- curve 

Interflow index. Determines the ratio of interflow 
to surface runoff 

Percent of groundwater recharge assigned to deep 
percolation 

Evaporation loss index for the lower zone (inches) 

Ratio of areal evapotranspiration to input 
evapotranspi rati on 

Parameters to compute watershed potential evapo- 
transpiration from free water potential evapotrans- 
piration (defined in section 4.6) 

EHIGH and ELOW can vary for each subarea 

NEP and NDUR are regional parameters assigned to 

the evaporation input station 

Percent of watershed stream surfaces and riparian 
vegetation 

Percent of surface detention reaching the channel 
each hour 
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r, LIRC6 


s. LKK6 


t. 


KV 


Percent of interflow detention reaching the channel 
each 6 hours 

LIRC6 l.O^(IRC)^^^ (4-1) 

where IRC is the SWH IV daily recession constant for 
Interflow. 

Percent of groundwater storage that reaches the 
channel each 6 hours when KV zero 

IKK6 = 1.0-(KK24)^/^ , (4-2) 

where KK24 is the SWM IV minimum observed daily 
groundwater recession constant. 

Weighting factor to allow variable groundwater 
recession rates. 


NOTE: The basic 6-hour groundwater flow (6WF) equation is: 
GWF = LKK6-{1.0+KV-6WS)-S6W (4-3) 


where: GWS is the antecedent groundwater inflow index 
and SGW is storage in groundwater (inches). 

u. KGS Recession factor for antecedent groundwater inflow 
index. 
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Channel Routing 


The conceptual distributive NWSRFS model package is not a 
complete simulation model i’n that actual stream channel ^characteristics 
are handled by a hydrological procedure termed Lag and K channel 
routing. This approach can be made more "real" by reducing the areas 
of the basin to very small units. The following paragraphs outline 
the channel system that is now in use. 

FLOW ROUTING PROCEDURE 

Lag and K channel routing, as described by Linsley, Kohler 
and Paulhus in Hydrology for Engineers , is used. The essence of this 
procedure is to: (1) introduce a time delay (lag) to account for travel 
time of a wave through a reach, and (2) simulate wave attenuation in the 
reach caused by channel storage effects. The attenuation is simulated 
by routing the reach inflow, suitably lagged, through a hypothetical 
reservoir governed by the equation: 

f = Kt)-Q(t) = . 

in which the reservoir storage constant K gives rise to the second half 
of the method name "lag and K." The reservoir storage is given by S, and 
its inflow and outflow are given by I and Q, respectively. 

CONSTANT LAG 

Local Runoff 

In the conceptual framework of the soil moisture accounting 
procedure, the runoff produced in a 6-hour interval is the flow volume 
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delivered to the channel system in that period. The first step in 
channel routing is to apply a constant lag to this channel inflow. 

This is accomplished by the time-delay histogram. The channel system 
is divided into reaches v/hich have equal travel time. Currently in 
NWSRFS a 6- hour time interval is used for routing computations; thus, 
the channel reaches have travel times that are multiples of 6 hours. 

Each element of the time delay histogram is associated with 
a travel time zone. For example, element three is associated with a 
travel time between 12 and 18 hours. Each element of the time delay 
histogram is merely a summation of the fraction of the area contributing 
to all reaches with the same travel time. The total time-delay histogram 
is a tabulation of these summations and must equal unity. 

To account for areal variation in runoff, each element of the 
time-delay histogram can have channel inflow from separate soil moisture 
accounting computations. 

Upstream Flows 

This value represents the time in hours for a channel wave to 
travel from the upstream inflow point to the reach outlet, 

VARIABLE LAG 

Some channel systems exhibit a lag that varies with inflow. 

In the NWSRFS the total lag consists of the constant lag component plus 
a variable component. The variable lag Is applied to upstream Inflows 
and local runoff after constant lag has been applied and after these 
lagged flows have been added together. 
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AHENUATION BY CHANNEL STORAGE . 

This is the "K" part of the routing. The attenuation by 
channel storage is simulated by routing the lagged flow through a hypo- 
thetical reservoir with storage constant K. The reservoir inflow will 
have undergone both constant lag and variable lag, so let's call it ly 
to distinguish it from the constant lagged flow of the previous 
section. 

The hypothetical reservoir is governed by the equation: 


where S is the reservoir storage, K the reservoir storage constant, and 
I and Q are the reservoir inflow and outflow, respectively. The above 
equation is exact for instantaneous value, but is used to estimate the 
behavior of the hypothetical reservoir over a 6-hour interval. In particu 
lar, it is used as: 

T-q = K(f) 

This equation is not necessarily exact. T (identically the lagged 
inflow Iv) is the average inflow during the period. The interval values 
Q and (dQ/dt) are estimated by instantaneous outflow values as: 

Q=(Q2 + Qi)/2 

= (Q2 - Qi)/4t 

Here Q] is the instantaneous flow at the flow point at the end of the 
last time period, a known quantity. 
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Solving for the desired instantaneous outflow at the end of 


the period (At = 6 hours) gives; 



For some channel reaches, the same K value Is sufficient for all flow 
levels. Other channel reaches require K as a function of flow (vari- 
able K). As an example of the use of this curve suppose the midnight 

■ 

flow (Q-j) v/as 33,000 cfs and the average lagged inflow for the 6-hour 
interval midnight - 6 a.m. is computed as ly == 26,000 cfs. The simulated 
6 a.m. flow would be obtained as follows: 

a. Interpolate between the K vs. outflow points to obtain K: 


K = 15.0 + (11.3-15.0) 


.. (33,000-30,000) 
(37,000-30,000) 


= 13.41 hours 

fa. Plug into routing equation 


0 = 26.000 (-6 ) + 33^000 (1^) 

46 a.m. 16.41 16.41 


= 30,440 cfs. 


Figure B-6 summarizes the computations of constant lag, 
variable lag, constant K, and variable K that have been described in 
the preceding sections. 


MHSRFS Operations Scenario 


Can Basin Archive 

(*) Soils (LANDSAT) 

* Erosion areas 

* Vegetation (LANDSAT) 

Slope (roughness) (topographic charts) 
(*) Impervious areas (LANDSAT) 

Interflow Index (historical) 
Infiltration Index (historical) 
Antecedent flow (prior run) 

* Albedo (LANDSAT/Metsat) 

Ground water flow (ground observation) 

* Water area (LANDSAT/Metsat) 

Stream flow station (location maps) 
Constant Lag values 

Variable Lag values 
Constant K 
Variable K 
Reservoir ID 

Calculate Operating Archive 

Impervious areas/basin element 
Vegetation cover/basin element 
Soil water - Holding Capacity Index 
Albedo/basin element 
Water, area/basin element 
Aspect/basin element) 


SLEPBOPUCBIUTy Of fHF’ 
page 18 POOP 
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Call Basin Daily 

(i) Precipitation Observations 


* 

* 

* 




* 


(i) 

(+) 

(t) 


* 


(i) 


{*) 


Satellite cloud cover 
Satellite snow cover" 

Water area 
Soil moisture 
o Budget 
° ESHR 

o Ground Observations 
Temperature surface (Max-Min) 
Q VHRR 

o Ground Observations 
Dew point (surface) 

0 Ground Observations 
Temperature (altitude) 

Wind speed 

Satellite snow melt areas 
Satellite ice dam areas 
Satellite water area 
Stream flow/basin element 
- ■i’ate 
“ volume 
Evaporation 

(+) - ground observations 
- satellite derived 


Calculate Basin Water Status 


Land Phase 

Mean basin element precipitation 

Mean basin element snow melt 

Mean basin element snow area change (plus or minus) 

Mean basin element potential evapotranspiration 
Mean basin element overland flow 
Mean basin element interflow 
Mean basin element infiltration per zone 
Mean basin element deep ground water recharge 
Mean basin element active ground water storage 
Mean basin element evapotranspiration per zone 
Mean basin element interception 
Mean basin element total evapotranspiration 
Mean basin soil moisture profile end of process interval 
Mean basin element inflow to channel system 
Mean basin element solar radiation 
Channel Phase 

Per basin element inflow 
Flowpoint flow 


* Indicate direct satellite derived quantities 
(*) Indicate potential satellite derived quantities 
(f) Indicate telemetry data 
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** The satellite-den'ved information can in the future be extended 
to include for some areas: 

o Variable lag information 
o Infiltration index 
o Slope (?) 
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